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PREFACE 


ThP Environment for ^p„lic,ation Software Integration and 

Execution (EASIE) provides doth a methodology and a set of 

- rv i-ho ta«;l( of coordinating 

software utility programs to ease the task 

engineering design and analysis codes. The need for sue 
technigues and tools has stemmed from the computer-aided design 
end engineering activities within Ungley Research Center's Space 
systems Division (SSO). In SSD. the Vehicle Analysis Branch 
(VAB). with emphasis on advanced transportation systems, and t e 
spacecraft Analysis Branch (SAB), with emphasis on advanced 
spacecraft, share a common need to integrate many stand-alone 
engineering analysis programs into coordinated, gui ck-turnaroun 
aser-friendly design systems. In particular, the most needed 
,3,a„Hties include easy selection of application programs 
goick review and modification of program input/output data, an 
logging of the actual steps that were ekecuted during the 
study. Although the application programs used hy VAB an 
OHfer. the design methods used hy their engineers are guite 

Similar, and great efficiency can be gamed by providing 

. that orovides the capabilities mentioned 
computer environment that provmeb 

above. , 

EASU is a user interface and set of utility programs which 

supports rapid integratioh and evecution of programs about a 

central relational database. In general, the EAS.E system 

uddresses the heeds of four differeht classes of people who w„ I 
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be involved the development of an engineering design system. 
Certain individuals may serve in more than one of these roles. 

bot the following terms will help to clarify several distinct 
activities associated with the EASIE system. 

The first classification represents the engineer/designer/ 
analyst. This group conducts the design study by executing 
modeling and analysis programs and generating data required to 
evaluate the design against Us objectives. EASIE documentation 
will refer to this group as EASIE system users or, more often, as 
users. In general, these users are only interested in executing 
programs already installed into an EASIE design system. 

A second group aided by EASIE Is identified as application 

programmers. These programmers are responsible for the 

development and Improvement of modeling and analysis programs 

used in the engineering design process. They are the experts 

with respect to particular application programs and can define 

Its input and output variables. This must be done before 

inclusion of that program with others Into the integrated 
system. 

The third group is identified as program Implementers since 
their function is to provide an environment where all the 
software tools work together with a minimum of effort. These 
people will use information provided by the application 
programmers and will install or modify the programs in an EASIE 
system by creating appropriate data constructs In the database 
and locating files where needed by the EASIE executive. 


The fourth classification is design team leader or design 
manager. This is the individual or group responsible for 
identifying parameters important to the design study and for 
configuration management of the data as it is produced by the 
design team. This design manager must have an overview of the 
total data requirements for the analysis process and must be 
concerned foremost with the integrity of the data. 

With these terms defined, the four volumes of EASIF. 
documentation can be associated with the groups most likely to 
use then. Each of the volumes addresses different aspects of the 
support tools, and each is intended to be independent of the 

others . 

Volume I, EXECUTIVE OVERVIEW, provides information about the 
functions, concepts, and historical development of EASIE and 
should be read by anyone trying to determine if EASIE would be 
beneficial to thei r work . 

Volume II, PROGRAM INTEGRATION GUIDE, describes the portion 
of the EASIE tools supporting both the integration of appl i cat i on 
programs into a central database and the definition of the data 
dictionary used during data review and modification. This volume 
will be used primarily by the program implementer and the design 
manager in their responsibilities for the actual installation of 
appropriate programs into a fully-integrated design system. 
However, the application programmer may also use tools described 
in this volume to assist in the documentation of input/output 
variables for the application program. 
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Volume III, PROGRAM EXECUTION GUIDE, describes the portion 
of the EASIE tools supporting the selection and execution of 
application programs, building of menus, and editing of program 
data. This volume will be of foremost importance to the users 
who will perform design studies. In addition, the program 
implenenters will find the sections concerning the construction 
of application-dependent procedures helpful. Finally this 
document will also be used by the design manager for reviewing 
dataanddesignactivities. 

Volume IV, SYSTEM INSTALLATION AND MAINTENANCE GUIDE, 
describes the procedure of loading the EASIE system onto a 
computer. It also gives some insight into the hardware and 
software dependencies of the EASIE code. This, most likely, will 
be needed by the program implementer to familiarize himself with 
the directory structure and location of the various EASIE 
components. Although the design of EASIE is intended to reduce 
the system dependencies, this version nevertheless reflects in 
several ways the current implementation using the Relational 
Information Management (RIM*) database management system and the 
VAX/VMS'*' operating system. 


★ 
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1.0 INTRODUCTION 


The purpose of this document is to present a set of software 
tools designed to aid in the complex task of integrating a 
collection of application programs into a single system. The 
Environment for Application Software Integration and Execution 
(EASIE) tools offer a program integration approach critical in 
defining and forming the data paths for inter-program 
communi cati on . 

This document is intended for programmers faced with the 
problems of program integration or program interfacing. For 
readers unfamiliar with the rigors of program, integration, the 
following BACKGROUND section provides the necessary motivation. 
Although the acronym EASIE implies simplicity, the problems 
encountered when integrating two or more programs are often 
formidable. Consequently, the potential EASIE user should 
anticipate a relatively high learning curve upon initial exposure 
to the database management system (DBMS) terminology and software 
tools. One of the principal advantages of using the EASIE tools 
is that once the initial learning hurdle is conquered, the 
learned program integration techniques are applicable to other 
programs or sets of programs. 

In addition to a knowledge of the program integration 
problem, the reader should have some experience with DBMS 
terminology and techniques. In particular, the EASIE tools rely 
heavily on the techniques of the relational approach to DBMS such 
as those described by C. J. DATE [l]i More specifically, the 
EASIE tools are built upon the Relational Information Management 


1 


(RIM) DBMS [2]. However, as explained later in this document, 
the EASIE tools are DBMS independent. 

The computing environment in which the EASIE tools were 
developed is a DEC VAX 11/785 running VMS 4.5. In some sections 
of this document, necessary references are made to VMS utilities, 
symbols, and other DEC system features. The interested reader 
should consult DEC documentation for further details. The source 
language is DEC'S version of FORTRAN 77. Because certain EASIE 
utilities involve code generation in the form of FORTRAN 
subroutines, the prospective user should be familiar with FORTRAN 
language constructs. 

The first few sections of this document provide background 
information on the program integration problem. The majority of 
this document is organized as a tutorial whereby new terms and 
concepts are introduced as they are encountered in the normal 
course of the program integration process. A SIMPLE INTEGRATION 
EXAMPLE section introduces the basic features of the EASIE tools, 
defines the relevant terminology, illustrates the menu and 
command driven user interface, and concludes with program 
execution. EASIE provides an environment for both program 
integration and execution. As the name signifies, A MORE COMPLEX 
EXAMPLE section details additional features of the EASIE DBMS 
tools using a more sophisticated program integration problem. 
The last two sections are reference guides to the SYSTEM LIBRARY 
PROCESSOR Menu Options and to the REVIEWER commands including 
ranges, 1 i mi t i at i on s , capabilities, and defaults. 
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The architecture of the EASIE user interfaces 

as .ac as poss..^, to .e ,oaopoo.oot ot t.e .atatase 

„.„a,e.eot systo. (0««S, sottwaoo an. computer nar.wana » 
V„,u.e H. .KSmtAHON AKH «A,NT„AN« OUIOE 

aescribes tbe considerations important to portion tbe 
systen to otner computer system osinn other DBHS software 
EASIE Volume lU, PROGRAM EXECUTION GUIDE [4], can be 
^oaependent of tbe other EASIE Volumes, and provides the 

noidelines for tbe selection and execution of application 
programs, building menus, reviewing data, and editing program 

w T T FXFCUTIVE overview [5], contains the 
input data. EASIE Volume I. EXECUTl 

.. that is useful in determining if EASIE would be 

information that is useiui 

beneficial to a specific project or study. 
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2.0 BACKGROUND 

"ver the past 35 yeats. the ese of computer aids In 

engineering has increased exponentially. Today, much work that a 

few years ago „ight have taken weeks can he done in seconds 

Application programs are available for virtoally all engineering 
disciplines. 

TAis growth has not been void of probleais. while 
information may be obtained at a faster rate and in greater 
bundance, the absence of standardi tati on and lack of 
coordination among software developers has resulted in the 
proliferation of computer programs unahle to communicate data to 
other programs. Although two programs may use the same data, 
physical restrictions imposed by the computer environment may 
'"hibit the communication of the data between the programs. The 
price being paid for this state of affairs is often the manual 
transfer of data from one program to another with the associated 
manpower loss, time delay, and potential for error 
introduction. Several approaches can be taken to address this 
problem. This document describes a set of software tools 

designed to implement one approach used at LaRC for its 

efficiency and flexibility. A brief example will serve to 

compare these approaches. 

Assume a modeling program (PROGA) has been purchased from 

Company A and an analysis program (PROGB) from Company B. Among 
the output from PROGA is the TOTAL MODEL MASS written to an 

unformatted file. PBOGB requires the TOTAL MODEL MASS for input, 
but the program is designed to read it from a formatted file.’ 
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Logically, these programs could communicate data (TOTAL MODEL 
MASS), though physically this communication is impossible due to 
differing data environments (formatted versus unformatted 

files). Consequently, some change must be made to enable the 

transfer of data. This is typical of the problems faced when 
several programs are to share data within a design activity. 

At least three possible methods exist to facilitate 
communication between programs under such circumstances: 

(1) Modify one or both programs (program i nt eg ra t i on ) . 

(2) Develop a translator to convert the output of PROGA 
into an acceptable input format for PROGB (program 

i nterf aci ng ) . 

(3) Use a database management system (DBMS) to store the 
output from PROGA into the database and retrieve the 
input for PROGB from the database. 

For this example, method (1) appears to be the simplest, most 

efficient means to communicate data. PROGA can be modified to 

output TOTAL MODEL MASS in a format acceptable to PROGB. 

However, the real world is seldom so simple. In a realistic 

example, PROGA would likely produce abundant output of which only 

a portion would be required by PROGB. Format conversion would 

not be the only problem to solve. All possible output statements 

would have to be located and understood before the format 

conversion could be completed. In a large, complex program, this 

would not be a trivial task. 

The scenario can be worse. Suppose PROGA is to supply 
inputs to several programs in the integrated system, each 
requiring data in different formats. PROGA would require 
modifications to output, possibly the same data, to several 
output files (additional overhead). 


5 


<\lthough program complexity may render this approach 
impractical, purchasing agreements may make it impossible. Many 
software products are acquired without access to source code and 
therefore may not be modified. 

For this example, method (2) solves some of these 
problems. Although the internal structure of programs is often 
not readily accessible (complex code or no code), the inputs to 
and outputs from programs are usually well documented. A 
translator program could be developed to read as input the output 
of PROGA and write an output file acceptable as input to PROGB. 
This method has the advantage of requiring no modification to 
either program, but introduces additional overhead as it reads, 
converts, and writes. Also, a separate translator would he 
required for each application. 

Method (3) may be implemented as a variation of either 
method (1) or method (2). Using method (3), data are retrieved 
from and stored in a relational database rather than converted 
directly to another format. Using the simplified example, PROGA 
could be modified to store TOTAL MODEL MASS directly into a 
relational database; or if no source code is available, a 
translator could be developed to read the output file from PROGA 
and store TOTAL MODEL MASS in the database. PROGB could then 
retrieve TOTAL MODEL MASS from the database by using either 
method (1) or (2). In some cases, method (3) imposes additional 
overhead because the data must be manipulated by the DBMS being 
used and programmers with experience in using the selected DBMS 
are required. However, there are significant advantages to be 
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gained when program integration is accomplished through method 
(3). A DBMS is a collection of tools designed for fast random 
access storage and retrieval of data allowing organization and 
referencing of data by logical relationships without concern for 
the physical file organization. If such tools are used 
exclusively in program integration, they establish standards for 
the physical storage of data and reduce communication problems 
associated with the data environment (differing formats). 

Because of their random access capabilities, the DBMS tools 
may increase efficiency in cases where small amounts of data are 
required from a large output. Suppose PROGA outputs TOTAL MODEL 
MASS at the end of a large output file. By method (2), if PROGB 
and PROGC required TOTAL MODEL MASS, translators for both would 
have to process the entire output file to locate the datum. 
Using a DBMS, after the output from PROGA is stored in the 
database, TOTAL MODEL MASS may be retrieved quickly without 
unproductive processing. But most important, any new programs 
added to the design activity that require output from PROGA can 
access that datum without requiring further modification to PROGA 
or its translator. 

Although the advantages provided through method (3) are 
attractive, especially when numerous programs are to be 
coordinated, many programmers are hesitant to use a DBMS because 
of the additional knowledge required. Not only are programmers 
experienced with the interface to the DBMS required, but the 
portability of the resultant software is reduced. If the 
software is to be moved to another computer, the new machine must 
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have the selected DBMS. Conversions to other DBMS's are usually 
costly and time consuming. Even conversions from one computer to 
another , using the same DBMS, may require substantial software 
changes . 

An alternative is required that retains the advantages of 
using a DBMS while minimizing the impact on the program 
integrator. The EASIE data management tools are designed to 
offer such an alternative. EASIE does not eliminate the need for 
knowledge of a relational approach to database management, but 
does reduce the need for specific knowledge of the interface to 
the selected DBMS. These tools, which are addressed in the 
remainder of this document, are based upon a processor which 
makes the DBMS transparent to the user, while providing the 
functions needed to quickly integrate (interface) programs around 
a central database. The speed and versatility of the DBMS 
approach make it the most productive method for the development 
of a system of integrated programs. 
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3.0 THE EASIE TOOLS FOR DATABASE MANAGEMENT AND PROGRAM 

INTEGRATION 

The EASIE DBMS tools allow programmers to work at a higher 
level of abstraction than that provided through conventional 
DBMS's. Using a user-friendly, interactive processor, the schema 
of the database is described (relation names and descriptions; 
attribute names and descriptions; data types; dimensions; and 
units). Next, the data (program input or output) required for 
each particular application are identified in an input or output 
template. This template information, referred to as the SYSTEM 
LIBRARY, is stored in the database and aids in the automation of 
several tasks in the integration effort. Having described the 
required relations, the initial database schema is automatically 
produced. Using a generic editor, referred to as the REVIEWER, 
and the template specification for the application program, a 
consistent systematic method is provided to review/modify the 
input or review the output for any program. Also, using the 
template specification. FORTRAN subroutines are generated 
automatically to retrieve data (for an input template) from the 
database into a program's local variables. Similarly, 

subroutines are generated to store data (for an output template) 

from local variables into the database. 

Using the EASIE tools, conventional tasks for database 
integration are substantially reduced, program maintenance is 
simplified, and the program integration task is more straight- 
forward. In the following sections of this document, a simple 
example using EASIE is presented providing the minimum discussion 
needed to complete the example. A later section presents a more 
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complex example using additional EASIE techniques. The final 
sections provide a complete reference guide to the EASIE tools. 


3.1 Parameter Versus Attribute 

Conventionally, a relational DBMS allows for organization of 
data into tables, called relations, consisting of rows (tuples) 
and columns (attributes) which provide storage for the matrix of 
data. Most DBMS's do not provide a convenient means for storing 
parametric data (data not representable by a matrix). For 
example, in a modeling system, mass and volume of parts may be 


represented 

by a table: 





Part Name 

Mass 


Vo 1 ume 


TOP 


~rr- 


“TTT^i — 


MIDDLE 

20 


200 


BOTTOM 

30 


300 


A database 

relation representing 

this 

table may 

be defined with 

attri butes : 

pa rt name , 

mass, and 

volume. Each part would have a 

tuple entry 

giving the 

actual values 

for each 

part. But how 

would the total model 

mass and 

total 

model volume be stored? 


Here a relation (matrix) representation is not appropriate. 
EASIE provides for a special relation type defined as PARAMETER 
type. A parameter relation is a collection of parameters of 
varying types and dimensions that logically belong together. 
Thus, a parameter relation could be defined as follows: 

Val ue 


Parameter name 
TOTMASS 
TOTVOL 


TO- 

600 


to contain the values for total model mass (TOTMASS) and total 
model volume (TOTVOL). 
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In EASIE, the conventional matrix relation is called 
ATTRIBUTE type. 


3.2 Integration Using The Conventional Approach 

To integrate a program with a DBMS, the following steps must 
be taken : 

(1) Examine the program and identify all data to be read 
from the database (input) or written to the database 
(output ) . 

(2) Group the data into relations according to 

logical relationships among the data accounting for 

various types, dimensions, etc. Organize the 

retri eval /output of data from/to the database required 
by each program. 

(3) Using the DBMS, create a database containing the 

schema for the required relations. 

(4) Using the FORTRAN interface library of the DBMS, write 
FORTRAN code to retrieve input from the database and 
store output into the database. 

(5) Because the interactive data modification capabilities 
available with the DBMS are often not suitable for 
efficient data modification, a FORTRAN processor may be 
required to facilitate input modification and output 
review. This processor may be called from within the 
program (integrated) or executed as pre- (input review) 
or post- (output review) processor to the program 
( i nterfaced ) . 

Often steps (3), (4), and (5) are the most difficult, time- 

consuming, and error-prone activities. They also represent the 
portion of this process that requires specific knowledge of the 
selected ORMS. Using the EASIE tools, these steps are automated 
to the extent that schemata, FORTRAN database I/O routines, and 
the review capabilities are produced without the need for such 
knowl edge . 
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3.3 Integration Using EASIE 

Within EASIE, information about the database and program 
interaction with the database is recorded using an interactive 
program, the SYSTEM LIBRARY PROCESSOR. A data dictionary is 
constructed containing the name and description of each relation; 
and the name, type, dimension, description, and units of each 
parameter/attribute of the relation. A template library is 
constructed containing the input and output templates required by 
programs integrated with the database. A template is a 

description of all relation subsets required as input/output 
to/ from a program. A program library is constructed storing 
information about each program integrated into the system; i.e., 
location, execution procedure, input and output templates, etc. 
All of this information is stored in a RIM database. The SYSTEM 

LIBRARY. 

Once this information is recorded in the SYSTEM LIBRARY 
database, the SYSTEM LIBRARY PROCESSOR can automatically produce: 

(1) an input file or FORTRAN program to create the schema 
for the database with which the programs will be 
integrated. 

(2) FORTRAN subroutines to retrieve input and store output 
from/to the database for each program (using the input 
and output templates). Oata are retrieved/stored 
from/in the database into/from variables in the 
subroutines that have the same names as the parameters/ 
attributes in the target relation. All communication 
code using the FORTRAN interface to the DBMS is con- 
structed by the processor. 

(3) an input file to a generic REVIEWER program. The 
file consists of an input or output template and 
instructs the REVIEWER on which information to extract 
from the database for review or modification. There- 
fore, the one REVIEWER program may be used to retrieve 
or modify data for any application. 
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After creating the schema for the database using output from 
the processor, default input data may be established using the 
REVIEWER providing one or more Master databases [6] exist and 
which may be copied and modified. The generated FORTRAN routines 
to retrieve/store data must be modified by the integrator to 

communicate data to/from the program by: 

(1) adding parameter and/or common blocks to the subroutine 
to pass the values from/to the va r i abl es decl a red by 
the processor. Also, the routine calling statement 
must be placed at the appropriate location in the 
applications program (program integration). 

(2) creating a preprocessor (for input templates) or 
p 0 s t - p r oce s s 0 r (for output templates). The routines 
are modified to create a stand-alone program that, 
after reading the database, will write an input file 
for the program or, after reading the output file, 
store the data in the database (program inter- 
fa c i n g ) . 

In either case, database interaction has been automated. 
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4.0 A SIMPLE INTEGRATION EXAMPLE 


The following is a step-by-step example to Illustrate the 

integration of a program with a database. Suppose a program, 

BOX, is to be integrated with a database, BOX accepts as input 

the length, width, and height of a box and computes its volume. 

Step 1: Length, width, and height (real numbers of dimension 1) 
are required as input in units of meters(M). Volume 

(real number of dimension 1) is output in cubic meters 
(M**3). To aid in the process of defining relations, a 
standard form is suggested (Appendix F). 

Step 2: All values are parameter type (represent no row/column 
relationship) and will be placed in a single relation 

niMEN. Before proceeding to steps (3), (4), and (5), 

the SYSTEM LIBRARY must be constructed. 


4.1 Constructing The SYSTEM LIBRARY 

The SYSTEM LIBRARY is physically a RIM database and the 
schema must be established before entering data. The SYSTEM 
LIBRARY database is initially created by executing the VMS 
command : 


PTOAIDE : [RUILD_niCT]BUILDniCT.COM<CR> 

(See Appendix G for definition of symbols and logicals in VMS). 
This places in the current directory a RIM database named DICT 
containing the schema for the SYSTEM LIBRARY. The RIM database 
consists of three files; DICT1.DAT, niCT2.nAT, and DICT3.DAT. 

The SYSTEM LIBRARY PROCESSOR is executed in the same 
directory containing the SYSTEM LIBRARY database by the command: 
RUNDICT<CR> 

resulting in the display of the following prompt. 

ENTER NUMBER OF CHARACTER/WORD FOR TARGET SYSTEM: 

4 FOR RIM ON PRIME/VAX 
10 FOR RIM ON NOS 
2 FOR SORC/PRL 
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In this example, FORTRAN code Is generated to interact with 
a RIH database on a VAX computer. Therefore, the selected 

response is 4. 

The next display reveals the processor's main menu. 

SELECT OPTION: 

BR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BE - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 


4^2 Defining The Data Dictionary 

The first task is to define the required relations (only 

niMEN in this example). Thus BR is selected, resulting 

series of queries to define a relation. 

ENTER RELATION NAME (OR <CR> WHEN DONE): 

Enter the relation name "DIMEN" <CR>. 

ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 

DIMEN is to be parameter type (enter 1 <CR>). 

ENTER RELATION DESCRIPTION (80 CHARACTERS). 

The relation description is used to later identify contents of a 

relation. Enter BOX DIMENSIONS. 

ENTER YOUR NAME (20 CHARACTERS): 

The name of the relation creator may be useful at a later time as 
new programs are integrated. Enter the creator's name (the 
current date is also recorded). Each parameter in the relation 
DIMEN must now be described following the prompt. 
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DEFINE THE RELATION DIMEN: 

The information necessary to describe a parameter is requested. 

Recall that the first parameter is named LENGTH, of type REAL, of 

dimension 1, and is measured in meters M. The parameter 

description is defined as BOX LENGTH. The following sequence of 

prompts and user responses (underlined) define the parameter 
length. 


P^’^^METER name (OR <CR> WHEN D0NE)> 

LENGTH <CR> 

R <CR> ^ T y P E > 

ENW PARAMETER OIMENSION (UP TO 3 SEPARATED BY C0MMAS)> 
■orMlFSION = 1 

ENTER PARAMETER DESCRIPTION> 

BOX LENGTH<CR> 

enter unit of MEASUREMENT (<CR> IF N/A)> 

TrTEF OUTPUT FORMAT (<CR> IF N/A)> 


<CR> 

to enter the parameter length 

(Y/N) (<CR> = N); 

Y<CR> 


INTO THE DATABASE 


Output format is entered as a <CR> to indicate that the default 
format for this type (real) is to be used by the REVIEWER. 
Following the last entry, the sequence is repeated for width 
(WIDTH, R, 1, BOX WIDTH, M, <CR>, Y), height (HEIGHT, R, 1 , BOX 
HEIGHT, M, <CR>, Y), and volume (VOLUME, R, 1, BOX VOLUME, M**3, 
<CR>. Y). If a mistake is made during the sequence, an N on the 
final response will eliminate the entire parameter definition 
from the DATA DICTIONARY, and the sequence for that parameter may 
be reentered. When the first prompt of the sequence appears 
following the definition of the final parameter/attribute, by 
entering a <CR> will end the relation DIMEN definition and the 
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following prompt will be repeated: 

ENTER RELATION NAME (OR <CR> WHEN OONE): 

The entry of another name would allow the definition of another 
relation. Because the example has only the relation niMEN, a 
<CR> will end the DATA DICTIONARY definition and return to the 
main menu. 

When a good working knowledge of EASIE is achieved, an 
implementer of a program requiring a large amount of input data, 
should use the BUILD EASIE utility described in Appendix E. 


4.3 Defining The Template Library 


The 

second 

step is to define the 

TEMPLATE LIBRARY. 

Two 

tempi ates 

are 

required for the 

appl i cati on program 

BOX. 

The 

i nput tempi ate 

( named BOXIN) in 

effect 

makes the statement, as 

input to 

program BOX, LENGTH, 

WIDTH, 

and HEIGHT 

are 

to be 

retri eved 

from 

the relation DIMEN. 

Similarly, 

the 

output 

tempi ate 

(named 

BOXOUT) in effect 

makes 

the statement 

, as 

output 


from program BOX, VOLUME is to be stored in the relation DIMEN. 

The main menu command, BT, is selected resulting in a series 

of queries to define a template. 

ENTER TEMPLATE NAME (OR <CR> WHEN OONE): 

Enter the input template name BOXIN. 

ENTER 1 IF INPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 

BOXIN, an input template, defines data to be retrieved from the 
database for input to the program BOX. The selected choice 
is 1. Following the prompt: 

IDENTIFY ALL INPUT RELATIONS FOR THE TEMPLATE 
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the information describing data to be retrieved is requested. 

Recall that input to the program BOX consisted of LENGTH, WIDTH, 

and HEIGHT from the relation DIMEN. Following the prompt: 

ENTER RELATION NAME (OR <CR> WHEN DONE): 

the name DIMEN is entered. Because DIMEN was previously defined 

as a parameter type relation, the response to the prompt 

ENTER i FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 

is 1 and the opportunity to review its parameters is provided by 
the following prompt: 

THE RELATION DIMEN IS ALREADY DEFINED AND HAS 4 PARAMETERS. 
DO YOU WANT TO SEE THEM (Y/N) (<CR>=N): 

An affirmative response, Y, results in the following display 

depicting necessary parameter information: 


PARAMETER NAME DIMl DIM2 DIMS TYPE NUMBER OF CHARACTERS 
LENGTH REAL 

WIDTH REAL 

HEIGHT REAL 

VOLUME REAL 

Following this display or a negative response, N, the next prompt 

provides the names of parameters to be retrieved. 

ENTER 0 IF ALL PARAMETERS ARE TO BE RETRIEVED 

OR 1 TO READ PARAMETERS TO BE RETRIEVED FROM A FILE 

OR 2 TO ENTER PARAMETERS TO BE RETRIEVED FROM THE TERMINAL 

A response of 2 allows input of the desired parameters by 

p rompt i ng , 

ENTER PARAMETER NAMES EACH FOLLOWED BY <CR>; 

(PARAMETER NAME=<CR> WHEN DONE) 

Recall that only LENGTH, WIDTH, and HEIGHT are required from 
DIMEN as input. A response of, 

LENGTH<CR> 

srrnTTRTT— 
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height<cr> 

<CR> 


ends the selection of parameters 


from the relation DIMEN and the 


i nqu i ry , 

YOU HAVE IDENTIFIED 3 PARAMETERS 

OK TO enter the RELATION DIMEN 
(Y/N) (<CR>=N); 

allows those selections to be entered 


TO BE RETRIEVED 

INTO THE TEMPLATE BOXIN 


into the template BOXIN 


(affirmative response). 

At this point, parameter/attributes from other relations 
could be added to the template BOKIN following the repeated 


prompt . 

ENTER RELATION NAME (OR <CR> WHEN DONE). 

As no other relations are required, a <CR> completes the series 
of queries for defining a template and Iterates the series for 
subsequent template definitions. The following sequence 

illustrates the definition of the output template ROXOUT (user 


responses are underlined) 


ENTER TEMPLATE NAME (OR <CR> WHEN DONE): 

B0X0UT<CR> 

INTER 1 'Tr INPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 

TRTWIFY all OUTPUT RELATIONS FOR THE TEMPLATE 

enter RELATION NAME (OR <CR> WHEN DONE): 

DIMEN<CR> _ 

TFtTFTTOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 

■Tfi-rTELATlON OIMEN IS ALREADY OEFIHEll AND HAS 
orvOU^WAN^ TO SEE THEM (Y/N) (<CR>=N): 

^ R^^ko^?J5ASE^)ER^^?0 ll 'EPug;"ROH A EU 

OR 2 TO ENTER PARAMETERS TO BE REPLACED FROM THE 

TERMINAL 

2<CR> 
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ENTER PARAMETER NAMES EACH FOLLOWED BY 
(PARAMETER NAME=<CR> WHEN DONE) 
VOLUME<CR> 

<CR7 


<CR> : 


' '’''"''METERS TO BE REPLACED 

B0X0U°T 

Y<CR> 


rrmr RELATION NAME (OR <CR> WHEN DONE)* 

/ro\ ^ 1- / . 


ENTER TEMPLATE NAME (OR <CR> WHEN DONE): 


The final <CR> returns to the processor's main menu marking the 
completion of the TEMPLATE LIBRARY definition. 


STEP 3: 

4.4 Constructing The Database Schema 

Having completed the DATA DICTIONARY and TEMPLATE LIBRARY 
descriptions, an input file to RIM must be created for database 

schema definition. The command BS allows the option for either 
of two DBMS's. 

ENTER 1 FOR RIM SCHEMA 

OR 2 FOR SDRC/PRL SCHEMA 

Because RIH is the DBMS for this exauiple, 1 is entered. The natie 

of a file to contain the schema definition is supplied following 
the prompt. 

ENTER SCHEMA DUMP FILE NAME 

OR ‘*0“ TO RETURN WITHOUT WRITING A FILE 

Entering SCHEMA.DAT (name selection is arbitrary) results in a 

file of that name in the current directory containing the schema 

definition. The schema for a single relation may be written to 

the file by naming the relation following the prompt: 

ENTER RELATION NAME FOR SCHEMA DUMP 

OR <CR> FOR COMPLETE DATABASE SCHEMA DUMP 
OR "Q" TO QUIT 


20 



The usual response (as in this example) is to create the schema 
for the complete database by entering a <CR>. 

Outside the EASIE processor, interactive RIM must be 
executed by issuing the following single commands (APPENDIX G), 
RUNRIM 

INPUT SCHEMA<CR> 

which creates the schema for the database under the default name 
DATADB. 

STEP 4: 

4.5 Producing FORTRAN Routines For Input And Output To/Froin The 
Database 

Most DBMS's provide a FORTRAN interface library of 
subroutines to access the database. Data are transferred from/to 
a relation one row (tuple) at a time using a one-dimensional 
array. If the attribute types of the relation differ (integer. 


real , 

character, 

etc. ) , 

a n 

integer and real 

array 

must 

be 

equivalenced for 

storage 

and 

packing/unpacking 

of the 

storage 

a may 

with the 

data in 

the 

order of the attributes 

i n 

the 


relation. (Character data may be packed into either the integer 
or real array.) In addition to packing/unpacking the storage 
array, other functions must be performed by these FORTRAN 
routines. The database must be opened. The relations to be 
accessed must be identified, and the search or sort conditions 
for locating the data of interest must be established. The DBMS 
error codes and row counts must be controlled. Without automatic 
procedures to generate such code, a substantial amount of code 
would need to be written by the program integration team and then 
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tested and proven correct, often a time-consuming activity. 
Frequently, this new code is scattered throughout the existing 
code, making future maintenance efforts more difficult. 

Using the BF command, an input or output template is used to 
automatically produce FORTRAN code for database interaction. 
Data are either retrieved from the database and stored into 
program variables (input template) or extracted from program 
variables and stored in the database (output template). FORTRAN 
declarative statements (name, type, and dimension) for these 
program variables are automatically generated by the processor. 
Variable names produced by the processor match the names of the 
parameters or attributes as they exist in the database. The only 
responsibility of the program integration team is to communicate 
these variables to the program. 

After issuing the BF command, the selected template name is 

supplied following the prompt: 

ENTER TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "Q" TO QUIT 

To produce input routines for this example, BOXIN is entered. 
Next, the file name to contain the input subroutines is provided 
following the prompt: 

ENTER GETDATA FILE NAME 

OR "Q" TO RETURN WITHOUT WRITING A FILE. 

Arbitrarily, BOXIN. FOR is entered. The next prompt: 

no YOU REQUIRE ANSI STANDARD CODE? (Y/N) (<CR>=N) 
provides the opportunity to reduce eight character 

paraneter/attribute names in the data dictionary to six 
characters (adhering to ANSI standards). This is done by 
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truncation of any characters beyond six and may result in 
variable name conflict. Because a VAX will accept eight 
character variable names, the answer is N. The final prompt: 

DO YOU WANT TO RENAME ANY OTHER PARAMETERS/ATTRIBUTES? 

(Y/N) (<CR>=N) 

allows variable names tQ be different from paraneter/att ri bute 
names in the data dictionary. Suppose the predefined parameter 
named LENGTH was to be assigned to an existing variable named L 
in the program. An affirmative answer to this inquiry would 
provide the opportunity to assign the value of LENGTH in the 
database into the variable L instead of the variable LENGTH. In 
this example, the parameter names are satisfactory for variable 
names. The answer is N, and the processor returns to the main 
menu. 

Once produced, the file BOXIN.FOR contains source code 

for a driver subroutine (GETOATA ) and for one subroutine for 

each relation to be accessed (1 in this case). The driver 

subroutine GETDAT A is the only routine that need be modified by 

the program implementor and may be seen in figure 1. Notice that 
the variables LENGTH, WIDTH, and HEIGHT, are all typed REAL with 
no dimension, and the database is given the default name of 

DATADB, reference the statement DBASE = (8HDATADB ). After 

the call to the subroutine RlOOl , the variables LENGTH, WIDTH, 

and HEIGHT will contain the values in the database for the 
parameters LENGTH, WIDTH, and HEIGHT. The only changes required 
by the program integrator are those necessary to communicate the 
variables back to the program via either arguments lists or 
common blocks. The parameters could be added to the CALL and 
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SUBROUTINE statements for the GETOATA_ subroutine. An 
alternative, and the method used in this example, is to add a 
common block containing the variables LENGTH, WIDTH, HEIGHT, 

and VOLUME to the GETDATA subroutine under the assumption 

that this common block also exists in the calling program. 


SUBROUTINE GETDATA_ 

C 

COMMON /0BNAME_/ DB ASE_, DB0PN_ 

REAL*8 DBASE_ 

LOGICAL DB0PN_ 

C 

C*** jhE parameters for the relation dimen ARE: 

REAL LENGTH 

REAL WIDTH 

REAL HEIGHT 

C 

C LOAD REQUIRED COMMON BLOCKS HERE: 

C 

INCLUDE 'BOXIN.COMMON/LIST' 

DRASE_ = (BHDATADB ) 

C 

CALL R 1 00 1_( LENGTH, WIDTH, HEIGHT) 

C 

C MAKE ANY NECESSARY RE -ASS I GNMENTS HERE: 

C 

INCLUDE 'BOXIN. ASSIGN/LIST' 

C 

RETURN 

C 

END 


Figure 1. - Subroutine GETDATA_ 


Not i ce the c omment , 

C LOAD REQUIRED COMMON, BLOCKS HERE:. 

Directly below is the VAX FORTRAN INCLUDE statement added by the 
implementer to the automatically-generated code. To add common 
blocks, the program integrator need only create a file using the 
name BOXIN. COMMON containing the required common blocks. No 
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changes are required in the file BOXIN.FOR. Thus a file named 
ROXIN. COMMON is then created containing the common block: 

COMMON /INDIMEN/ LE NGTH , W I D TH , HE I GHT . 

Also notice the comment, 

C MAKE ANY NECESSARY RE-ASSIGNMENTS HERE: 
following the call to the SUBROUTINE R1001_. If, for example, 
the database contained LENGTH in meters and the program expected 
input of LENGTH in feet, an assignment statement could be added 
at this point to make the proper unit conversion. As this is not 
the case in this example, no code additions are required here, 
and the statement, 

INCLUDE 'BOXIN. ASSIGN/L 1ST' 

should be deleted. The file BOXIN.FOR is now ready for 
compilation and linkage with the example program. 

The BF command must be re-executed for the output template 
BOXOUT. The following sequence of prompts and user responses 
(underlined) build the file BOXOUT. FOR containing the FORTRAN 
routines required to store VOLUME into the database, 

B F<CR> 

TTiTER"TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "0" TO QUIT 
B0X0UT<CR> 

enter WfDATA FILE NAME 

OR "Q" TO RETURN WITHOUT WRITING A FILE 

BOXOUT. F0R<CR> 

DO YOU RFQ'Ul'Rr ANSI STANDARD CODE? (Y/N) (<CR> = N) 

N<CR> 

W YOU WANT TO RENAME ANY OTHER PARAMETERS/ATTRIBUTES? 
(Y/N) (<CR>=N) 

N<CR> 


Similar to the file BOXIN.FOR, BOXOUT. FOR contains a driver 
SUBROUTINE PUTDATA and one subroutine for each relation to be 
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accessed (1 in this case), 
in figure 2 . 


The SUBROUTINE PIJTDATA may be seen 


SUBROUTINE PUTDATA 
C 

COMMON /DBNAME_/ OBASE_,DBOPN 
REAL*8 DBASE 
LOGICAL DB0P¥_ 

C 

C*** THE PARAMETERS FOR THE RELATION DIMEN ARE: 
REAL VOLUME 

C 

C LOAD REQUIRED COMMON BLOCKS HERE: 

C 

INCLUDE 'BOXOUT.COMMON/L 1ST ' 

DBASE_ = (8HDATA0B ) 

C 

C MAKE ANY NECESSARY R E -ASS I GNME NTS HERE: 

C 

INCLUDE 'BOXOUT. ASSIGN/LIST ■ 

C 

CALL W1001_(V0LUME) 

C 

RETURN 

C 

END 

Figure 2. - Subroutine PUTDATA 


Notice that the variable VOLUME is typed REAL with no 
dimension, and again the default database name DATADB is 

assigned to the variable DBASE . Noting the FORTRAN INCLUDE 

statement, the program implementer need only create a file named 
BOXOUT. COMMON containing the statement: 

COMMON /OUTDIMEN/ VOLUME. 

The common variable VOLUME is assumed to contain the proper 
value upon entry to the SUBROUTINE PUTDATA_. Any necessary 
format changes or other reassignments need to be made prior to 

the call to the SUBROUTINE WlOOl . As none are required here, 

the statement. 
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INCLUDE 'BOXOUT.ASSIGN/LIST' 

should be deleted. Immediately following the call to W1001__, the 
value of VOLUME is stored in the database. With the creation of 
the file BOXOUT. COMMON , the file BOXOUT.FOR is ready for 
compilation and linkage with the example program. 


4.6 Linking The Example Program 

The original program BOX is seen in figure 3A. Notice that 
length, width, and height are read from the file BOXIN.OAT and 
Volume is written to the file B0X0UT.DAT. 

PROGRAM BOX 

COMMON /INDIMEN/ LE NGTH , WI DTH , HE I GHT 
REAL LENGTH 

COMMON /OUTDIMEN/ VOLUME 
0PEM(8,FILE= 'BOXIN.OAT' ) 

READ(8,* )LENGTH,WIOTH,HE IGHT 
CLOSE (8) 

VOLUME = LENGTH * WIDTH * HEIGHT 
OPEN(9,FILE='BOXOUT.DAT' ) 

WRITE (9,* )VOLtJME 
CLOSE (9) 

END 

Figure 3A.- Original Program Box 

The modified example program (contained in the file BOX. FOR) 
is seen in figure 3B. 

PROGRAM BOX 

COMMON /INDIMEN/ LENGTH .WIDTH , HE 1 GHT 
REAL LENGTH 

COMMON /OUTDIMEN/ VOLUME 
C 

CALL GETDATA_ 

C 

VOLUME = LENGTH * WIDTH * HEIGHT 
C 

CALL PUTDATA 
C 

END 

Figure 3B.- Modified Program Box 
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Notice that former input data transfer statements (FORTRAN 
OPEN, READ, and CLOSE) are replaced by a single call to the 

SUBROUTINE GETDATA . Former output data transfer statements 

(OPEN, WRITE, and CLOSE) are replaced by a single call to 

the SUBROUTINE PUTDATA . Both common blocks (INDIMEN and 

nuTDIMEN) have been included. Following the call to GETDATA 
(input of LENGTH, WIDTH, and HEIGHT), VOLUME is computed and, 

through the call to PUTDATA_, stored in the database. The file 
BOX. FOR is compiled and linked via the following command sequence 
(created in the BOX.COM file), generating the executable file 
BOX. EXE. 

$F0R BOX. FOR 
$F0R BOXIN.FOR 
$F0R BOXOUT.FOR 
SLINK BOX. OBJ - 
+ BOXIN.OBJ - 
+ BOXOUT.OBJ - 
+ LOADR IM/L IBRARY 
SEXIT 


STEP 5: 

4.7 Creating REVIEWER Input Files 


To 

this point, the 

DATA 

DICTIONARY (DICT) and 

TEMPLATE 

LIBRARY 

(BOXIN, BOXOUT) 

have 

been created. Using 

them, a 

database 

schema , D ATAOB , 

and 

FORTRAN input/output 

routines 


(BOXIN.FOR, BOXOUT.FOR) have been created. These routines have 
been linked with the example program BOX which is now ready for 


execut i on 

by 

obta i n i ng 

i t s 

input from 

the 

database DATADB. 

However , 

no 

values 

for 

LENGTH , 

WIDTH, 

and 

HEIGHT have been 

establ i shed 

in the 

database 

ft 

Executi on 

at 

thi s poi nt woul d 

retrieve 

the 

value 

of zero 

(by 

defaul t ) 

for 

al 1 three val ues 


resulting in a computation of zero for volume. 
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step (5) of the integration using the conventional approach 
involves the use of the EASIE processor called the REVIEWER. 

Using the BRV command, a template is used to create an input 
file for a standard REVIEWER program. Using the REVIEWER, input 
values are changed and output values are examined. 

After entering the command BRV, the prompt: 


ENTER DIRECTORY LOCATION FOR REVIEWER INPUT FILES 
OR <CR> TO CREATE A LOCAL REVIEWER FILE 

allows the user to specify a directory location for the REVIEWER 

input file. This is important when using the directory structure 

recommended for use [6,7] with the EASIE EXECUTIVE. For this 

example, the REVIEWER input file remains in the current directory 

by entering a carriage return. In response to the prompt: 

'"^OR <CR>''TrCREATE REVIEWER FILES FDR ALL TEMPLATES 

OR "Q" TO QUIT 

the template name BOXIN is supplied. A tile is thus created in 
the current directory under the name ROXIN.REV containing input 
directing the REVIEWER to retrieve LENGTH, WinTH, and HEIGHT from 
the relation IIIMEN. The REVIEWER allows user modification and 


replacement of the data. 

Similarly, the following sequence of prompts and user 
responses (underlined) create a file in the current directory 
under the name BOXOUT.REV containing input directing the REVIEWER 
to retrieve VOLUME for review: 


EN T E ^ ^ IRECTORY LOCATION FOR REVIEWER INPUT FILES 
OR <CR> TO CREATE A LOCAL REVIEWER FILE 


<CR> 

“E N T E"R TEMPLATE NAME 
OR <CR> TO CREATE 


REVIEWER FILES 


FOR ALL TEMPLATES 


OR "0" TO QUIT 
BOXOUT<CR> 
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4,8 Executing The Example Program 

Having created both the input file for the REVIEWER 
(BOXIN.REV) and the executable file (BOX.EXE), input to the 

program BOX may be modified in the database by executing the 
command : 

REVIEW B0XIN<CR>. 

This will execute the REVIEWER using as input the file 

BOXIN.REV. Immediately the display in the top half of figure 4 

will appear. This demonstrates how the use of the SYSTEM LIBRARY 
PROCESSOR tools can automate most of the integration tasks even 
including an editing capability for data needed by the integrated 
programs . 

Issuing the commands (descriptions in brackets are not a 
part of the command), 

M 1 5<CR> [MODIFY LENGTH TO 5 METERS] 

M I 10<CR> [MODIFY WIDTH TO 10 METERS] 

M 3 15<CR> [MODIFY HEIGHT TO 15 METERS] 

R<CR> [REDRAW THE SCREEN] 

will modify the values for LENGTH, WIDTH, and HEIGHT and redraw 

the screen with the new values. The final screen display is 

shown in the bottom half of figure 4. Finally, the command: 

E <CR> 

will replace the values in the database. 

Execution of the example program will now retrieve these 
input values, compute VOLUME, and replace VOLUME in the 
database. The VMS command, 

RUN B0X.EXE<CR> 
will execute BOX. 
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Issuing the VMS comnand: 

REVIEW BOXOUT<CR> 

will execute the REVIEWER using as input the file BOXOUT.REV. 
Immediately the display in figure 5 will appear. Note the 
correct value of 750.000M^ has been computed for the parameter 
VOLUME. 


4.9 Concluding The Simple Example 

The following is a review of the process for integrating the 
program BOX. In the previous example, the SYSTEM LIBRARY 
PROCESSOR was used to: 

(1) Define a parameter relation (OIMEN). 

(2) Define input (BOXIN) and output (BOXOUT) templates 

accessing some portion of the relation OIMEN. 

(3) Build an input file for RIM to create the schema 

(SCHEMA.DAT) for DIMEN. 

(4) Build FORTRAN subroutines (BOXIN. FOR and BOXOUT. FOR) 
to access portions of the database as described in the 
input and output templates. 

(5) Build input files for the REVIEWER to review/modify 
data described by the input and output templates 
(BOXIN. REV and BOXOUT.REV). 

After modifications to the program BOX. FOR (to call the FORTRAN 
routines mentioned in step 4 above) and modifications to the 
input and output subroutines (that pass data to and from 
BOX. FOR), the three files, BOX. FOR, BOXIN. FOR, and BOXOUT. FOR 
were compiled and linked. Executing the REVIEWER using the input 
template BOXIN to establish LENGTH, WIDTH, and HEIGHT, was 
followed by execution of BOX (BOX. EXE) which stored the resultant 
VOLUME into the database. The computed value for VOLUME could be 
reviewed through execution of the REVIEWER using the output 
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template BOXOUT. 

To aid in the variable definition task, the EASIE Form 1 as 
explained in Appendix F may be useful. Notice that after 
designing the relations and templates (work that must be done in 
some form no matter what integration approach is used), the 
relations are placed in the DATA DICTIONARY. Anyone familiar 
with a relational DBMS (such as RIM) will recognize that this 
procedure, with the exception of defining parameter/attribute 
descriptions and units, is not more difficult than the 

conventional approach to define the database schema. Defining 
the templates may be argued to be additional work, but the 
procedure is simple and once completed much of the remaining 
difficult work required by the conventional approach is 

automated. Production of the schema is accomplished by 

instructing the SYSTEM LIBRARY PROCESSOR to create an input file 
which is read by RIM. Routines to interact with the database 
using the FORTRAN interface library of RIM are automatically 
produced leaving the program implementer responsible for the task 
of defining the FORTRAN communications of data from one 
subroutine to another (no special RIM knowledge required). Input 
to the generic REVIEWER program is automatically produced for any 
given template, and data can be reviewed or modified using the 
same techniques for any template, thus for any program. Recall 
that all steps but the actual execution are performed once for 
each program by the integration team. The designer/engineer 
performs the final steps of data review, data modification, and 
program execution. 

Obviously, many of the tedious, error-prone tasks required 
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using the conventional approach have been eliminated. However, 
other advantages may not yet be apparent. Because the FORTRAN 
I/O routines are produced automat i ca 1 1 y and data modification is 
accomplished using the REVIEWER, potentially any relational DBMS 
may be used. Originally, the EASIE tools were implemented using 
A Relational Information Management System (ARIS). Later, 
because of changing requirements at Langley Research Center, the 
tools were converted to use RIM. As needs changed, the 
capability to use PEARL (Structural Dynamics Research 
Corporation's I-DEAS system [8]) was added. During these 
transitions, no changes were required in the EASIE integrated 
programs. As the desired DBMS was changed, only new FORTRAN I/O 
routines and REVIEWER input files needed to be generated using 
the modified SYSTEM LIBRARY PROCESSOR. Since the REVIEWER uses 
the same commands and presents the data the same, there is no 
impact in this area regardless of the selected template or DBMS. 

Also, future maintenance efforts have been reduced. Anyone 
having worked on a large system of programs integrated into a 
DBMS using the conventional approach understands how such a 
system can create maintenance problems. Database interaction 
code written by a large group of programmers may be scattered 
throughout many I/O processors and programs. Coding standards 
may be established, but are difficult to enforce. Using EASIE, 
coding standards are established and enforced by using the SYSTEM 
LIBRARY PROCESSOR. Hand-written I/O processors are replaced by 
the REVIEWER. I/O subroutines are written by the processor, thus 
eliminating the need for a maintenance programmer to read or 
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write database interaction code. 

Conventional DBMS's usually provide a means to "dump" data 
to an ASCII file for data transfer from one database to 
another. If the data are logically the same but the schemata are 
different, conventional dump utilities cannot accommodate 
different schemata. Using EASIE, FORTRAN routines can be created 
to retrieve from one database and store in another. The 
programmer need only assign logically identical data from one 
variable to another. 
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CATEGORY 


1 : 


niMEN 


BOX DIMENSIONS 


L ! 

PRESENT VALUE ! 

1 NAME 

! SUBSCRIPT 

! DESCRIPTION 

! UNITS 

1 ! 
2 ! 
3 ! 

0.0000000 ! 
0.0000000 
0.0000000 ! 

LENGTH 

WIDTH 

HEIGHT 

! 

! 

1 

! BOX LENGTH 
! BOX WIDTH 
! BOX HEIGHT 

! M 
! M 
! M 


M n 
C n 
N n 
R : 
E : 
CAT 


; modify value (n = 1 i ne#,name(subscri pt) .or line range) 

: change category {n = id or name) 

: next page (n = + or - pages) „ 

reprint page, L n ; n 1ine#'s per page, X n : e^Pjnd line# n 
end and save mods, Q : quit without saving mods ^ H : help 
: list cateqories, SUB : defi 




EDIT: 

>M 1 5<CR> 
>M 2 lb<CR> 


>R<CR> 


BOX DIMENSIONS 


CATEGORY 1: OIMEN 


L 


PRESENT VALUE ! NAME 


SUBSCRIPT ! description ! UNITS 


1 [ 5.0000000 ! LENGTH 

2 i 10.0000000 ! WIDTH 

3 ! 15.0000000 ! HEIGHT 


! BOX LENGTH ! M 

! BOX WIDTH ! M 

! BOX HEIGHT ! M 


M n 
C n 
N n 
R : 
E : 
CAT 


: modify value (n = 1 ine#,name(subscript) ,or line range) 

: change category (n = id or name) 

; next page (n = + or - pages) „ 

reprint page. L n ; n line#'s per page, X n = expand line# n 
end and save mods, 0 : quit without saving mods, H ; he p 
• list categories, SUB : define review subset. T : toggle menu 


EDIT: 

>E<CR> 


Figure 4. - REVIEWER Display of Length, Width, and Height 



BOX 

DIMENSIONS 

CATEGORY 

1: 

OIMEN 


L 

! PRESENT VALUE 

! NAME ! 

SUBSCRIPT 

! DESCRIPTION 

! UNITS 

1 

! 750.0000000 

! VOLUME ! 


! BOX VOLUME 

! M**3 


M n : modify value (n = 1 ine#,name(subscript),or line range) 

C n : change category (n = id or name) 

N n : next page (n = + or - pages) 

R : reprint page, L n : n line#'s per page, X n : expand line# n 
E : end and save mods, Q : quit without saving mods, H : help 
CAT : list categories, SUB : define review subset, T : toggle menu 

EDIT: 

>Q<CR> 


Figure 5. - REVIEWER Display of Volume 
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5.0 A MORE COMPLEX EXAMPLE 

While the simple example does illustrate the major functions 
of the SYSTEM LIBRARY PROCESSOR and the standard flow of the 
program integration task, some additional capabilities available 
through the EASIE system may require further explanation. To 

accomplish this, a second example will be described. For the 
sake of brevity, the user prompts and proper responses are not 
embedded within the discussion, but rather are included in 

Appendix A. No step-by-step reference will be made to this 

appendix. It is highly desireable to follow along the printed 

screen text during the discu*ssion. 

In this example, the following new features will be 
demonstrated : 

(1) The use of Attribute relations (in addition to 
Parameter relations). 

(2) The use of character and integer data types and multi- 
dimensional data structures. 

(3) Program interfacing in addition to program integration. 

5.1 A Description Of The Programs 

Suppose two commercially available programs require 
communication. The program MAKGEO is available with source code 
(Appendix B) and receives as its input the length, width, and 
height of a box. MAKGEO outputs the geometry for the box 
centered at the origin with length along the X-axis, width along 
the Z-axis, and height along the Y-axis. The geometry output 
consists of an array of point coordinates (X, Y, Z) and an array 
of faces. (For each face, start at pointy, draw to pointj, draw 
to point|(, draw to point-] and draw to pointy, where i,j,k,l are 
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indices into the point array.) Because source code is available, 
user subroutines can be linked into the program to retrieve 
length, width, and height from the database and store the 
geometry into the database. This method, as in the simple 
example, represents program integration with the database. 

The program fiRAW is available only as an executable record, 
i.e. no FORTRAN source code. It is a generic display processor 
accepting as input a facet geometry description, i.e. points and 
faces as described above. Because no changes can be made to the 
input module of DRAW, an input file must be provided in the 
format (figure 6) acceptable to program DRAW. A preprocessor 
will be required to retrieve the geometry from the database and 
create a correctly formatted input file. The preprocessor must 
then be executed prior to execution of program DRAW. This method 
represents program interfacing with the database. 


MODEL NAME A80 

X, y, Z ROTATIONS IN RADIANS 3(E12.4) 

NUMBER OF NODE POINTS 15 

X, Y, Z COORDINATES OE FIRST NODE 3{E12.4) 


X, Y, Z COORDINATES OF LAST NODE 3(E12.4) 

NUMBER OF FACES 15 

FACE(1),FACE(2),FACE{3),FACE(4)F0R FIRST FACE 415 


FACE(1),FACE(2),FACE(3),FACE(4)F0R LAST FACE 4*15 


Figure 6. - Format Of Input File For The Program DRAW 
5.2 Defining The Relations 

Since the variables length, width, and height (input to 
MAKGEO) have previously been defined in the relation DIMEN, they 
do not require redefinition. Two relations require definition to 
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contain the geometry (output from MAKREO and input to DRAW.) 

These relations are defined using the RR command and include: 

X Y ^ i'/" attribute relation with attributes (columns) 

nltJrc r numbers, dimensioned ] and measured in 

meters.) The three attributes contain the X, Y and 7 

coordinates of the points. Each row then represents ’a three- 

dimensional point in space. The number of rows represents the 

number of points in the current model. 

fcoluln! ’-I" attribute relation with one attribute 

nd ces ’to dimensioned 4). containing the 

fslation COWS comprising a facet in the 
. ^ach row of the relation FACES represents a single face 

FACEfll ro f«E(l) row of oodes, drallng to 

pJrr Pi of nodes, drawing to FACE(3) row of nodes, drawing to 

FACFm r„ f 'a’ Closing the facet by drawing 

of nodes. Note that this relation could have been 
defined having 4 integer attributes each dimensioned 1 to contain 
indices to the NODES relation. The selected definition was 

at?HSute°relatPonP.‘' ‘'’""'cnsional capability for 


Notice in figure 6, that the program DRAW requires as input 
a model name (1st record of the input file as a character string 
of length 80) and X, Y, and Z rotation angles for the model (2nd 
record of the input file as three real values). A parameter 
relation, MODEL, is defined to contain these two parameters. 


5.3 Defining The Templates 

Using the BT command, an input template, MAKGEOIN, is 
defined for the program MAKGEO. The parameters LENGTH, WIDTH, 
and HEIGHT are to be retrieved from the relation DIMEN. 

During template creation, attribute relations present 
several options not applicable to parameter relations. In 
addition to selecting a subset of attributes, a subset of rows 
nay be specified by entering one or more WHERE clauses, stating 
conditions required for row selection. Example: where x greater 
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than 500. Rows may be retrieved, sorted by selected attributes, 
by entering a SORT clause. In this example neither of the 
special capabilities is required. There are also several options 
for replacing rows. For more detail on these options, reference 

sect i on 6, 3, 

An output template, MAKGEOOT. is defined for the program 
MAKCiEO. The attributes X, Y, and Z, are to be stored in the 
relation NODES, using no special conditions and no sort 

conditions. The rows are to be replaced such that only rows in 
the current model remain in NODES. All others are deleted, using 
the option, replace all tuples exclusively. All attributes, 
face, are to be stored in the relation F.ACES in the same way. 

An input template, ORAWIN, is defined for the program 
DRAW. All parameters are to be retrieved from the relation 

MODEL. All attributes are to be retrieved from the relations 

NODES and FACES using no special conditions and no sort 

conditions. 

No output template is required for the program DRAW because 
its output is a graphical display of the contents of MOnEL, 

NODES, and FACES. 

5.4 Building The Database Schema 

using the B5 command, an input file, called SCHEMA. IIAT, to 

interactive RIM is created which contains the commands to build 
the schema for the relations tllHEH, NOnES. EACES, and HOIIEL. 
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5.5 Building The FORTRAN I/O Subroutines 

Through the BF command, the input template MAKGEOIN is used 
to generate the file MAKGEOIN. FOR which contains the subroutines 
to retrieve length, width, and height from the relation OIMEN. 
Similarly, the template MAKGEOOT is used to generate the file 
MAKEGEOOT.FOR which contains the subroutines to store the model 
node points into the relation NODES and the model faces into the 
relation FACES. Because the attributes for NODES and FACES will 
be represented as FORTRAN arrays, dimensions are supplied for the 
array declarations. These dimensions should match the dimensions 
within the program. Because MAKGEO constructs a box. 8 nodes and 
6 faces are required. Finally, the template ORAWIN is used to 
generate the file ORAWIN. FOR which contains the subroutines to 
retrieve NAME and ROTATION from the relation MODEL, the model 
node points from the relation NODES, and the model faces from the 
relation FACES. Because the program DRAW is capable of 
displaying a model of up to 100 nodes and 100 faces, a dimension 

of 100 is selected for both NODES and FACES. 

5.6 Building The REVIEWER Input Files 

Prior to executing MAKGEO, values for LENGTH, WIOTH, and 
height most be established in the database. To provide this 

capability, a REVIEWER input file is created (HAKEGEO 1 N . REV ) 
using the template MAKGEOIN. 

Prior to executing DRAW, values for NAME and ROTATION should 
be established in the database. This capability is provided by 
creating a REVIEWER input file using the template DRAWIN. Recall 
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that in addition to MODEL, the relations NODES and FACES are also 
accessed by the template DRAWIN. Assuming a decision is made 

that geometry modification should only be allowed through 
modifications to LENGTH. WIDTH, and HEIGHT and re-execution of 

MAKGEO, a row modification flag in the template input file is set 
to 2 (no row modification) for both NODES and FACES. Other flag 
values would allow modification to the geometry using the 
REVIEWER. An alternative would have been to create a template 
which only accessed the relation MODEL. However, using the 

selected method, a user may review the geometry as NAME and 

ROTATION are modified, 

5.7 Preparing The Programs 

Use of the SYSTEM LIBRARY PROCESSOR is complete. The 

remaining tasks to complete the integration are: 

( 1 ) 

( 2 ) 

(3) 

(4) 

(5) 

( 6 ) 

The 
c omma nd : 


Read the SCHEMA.DAT input command file into interactive 
RIM to create the database. tctacLive 

Include common blocks in MAKGEOIN.FOR and MAKGEOOT FOR 
to communicate data to/from the program MAKGEO. 

PiJTDATA subroutines GETDATA and 

P0TDATA_ in the appropriate places. ~ 

MAi(rFnnT*^^^S objects of MAKGEOIN, 

MAKGEOOT and RIM library. 

Include FORTRAN code in the DRAWIN. FOR source file to 

ThiT^innllt program DRAW. 

This input file contains data retrieved from the 
database. 

Link DRAWIN object file and RIM library as a stand- 
a one program to be executed as a preprocessor to DRAW. 

schema for the database may be established by the 
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$RUNR IM 

followed by the RIM command: 

INPUT SCHEMA. 

Within the FORTRAN source code for the program MAKGEO, 
(MAKGEO.FOR, Appendix B) are the common blocks: 

COMMON/ I NO I MEN/LENGTH, WIDTH, HE I GHT 
C0MM0N/0UTGE0/X{8) ,Y(8) ,Z(8),NG,FACE (4,6),NF. 

A file named MAKGEO I N . COMMON must be created containing the 
common block INDIMEN. A file named MAKEGEOOT. COMMON must be 
created containing: 

COMMON/OUTGEO/X, Y,Z,N002_,FACE,N003_. 

Notice that dimensions for X, Y, Z, and FACE have been 
eliminated because they are contained in separate declarations 
within MAKGEOOT.FOR. 

Also, notice in the call to SUBROUTINE WlOO 2 (passing the 

parameters to be stored in relation NODES) are the parameters X, 
Y, and Z which are arrays containing the node points and the 
integer parameter N002_ that must contain the number of node rows 

to be stored in the database. N002 has then replaced NG in the 

common block OUTGEO. Similarly, in the call to SUBROUTINE W1003_, 

is the integer parameter N003 which must contain the number of 

face rows to be stored in the database. N003 has then replaced 

NF in the common block OUTGEO. 

Since no variable reassi gnments are necessary, the code 

line: 

INCLUDE 'MAKGEOIN. ASSIGN/LIST' 

is eliminated (by commenting) from the file MAKGEO I N . FOR . Also 
the code line: 
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INCLUDE 'MAKGEOOT. ASSIGN/LIST' 

is eliminated (by commenting) from the file MAKGEOOT. FOR . A 
recommended alternative approach is to create empty files using 
the names MAKGFO I N . ASS I GN and MAKGEOOT . ASS I GN thus preventing the 
need for the modifications to the files MAKGEOIN.FOR and 
MAKGEOOT. FOR. 

A call to SUBROUTINE GETDATA_(in file MAKGEOIN.FOR) is 
added to the beginning of the program MAKGEO, and a call to 

SUBROUTINE PUTOATA is added to the end of the program MAKGEO. 

MAKGEO. FOR, MAKGEOIN.FOR, and MAKGEOOT. FOR are compiled and 
linked using the file MAKGEO.COM. 

Execution of MAKGEO will now retrieve LENGTH, WIDTH, and 
HEIGHT from the database (call to GET0ATA_) passing these values 
V i a COMMON /I NDIMEN/ to the main program which will fill the 
arrays X, Y, Z, and FACE, and the parameters NG and NF with the 
geometry for the specified box. The main program will pass the 
values via COMMON/OUTGEO/ to SUBROUTINE PUTDATA_ which will 
store the geometry into the relations NODES and FACES. Recall 
that this method represents program integration with the 
database. 

Because the program DRAW is available as an executable file 
only, it cannot be modified. The file DRAWIN.FOR must be 
modified to become a stand-alone program that will retrieve the 
model name, rotations, and geometry from the database and format 
the data in a file as input to DRAW. 

The SUBROUTINE, RETURN, and COMMON INCLUDE statements are 
commented. 
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The file DRAW I N . ASS I GN is created, and contains the 
statements to write the model name, rotations, and geometry (in 

the required format) for the file DRAW.DAT. as input to the 
program DRAW. 

Notice that the program DRAW requires rotations to be input 
in radians, but in this example, rotations are stored in the 
database as degrees and converted to radians prior to writing the 
DRAW.DAT file. DRAWIN.FOR is compilied and linked using the file 
DRAWIN.COM. 

Execution of DRAWIN will now retrieve model name, rotations, 
and geometry from the database and create an input file DRAW.DAT 
to be used as input to the program DRAW. Recall that this method 
represents program interfacing with the database. 

5.8 Execution Of The Complex Example 

The VMS command: $REVIEW MAKGEOIN 

produces the display shown in Appendix C. 

The REVIEWER commands: 

M LENGTH 1 
M WIDTH 2 
M HEIGHT 3 
E 

to establish LENGTH, WIDTH, and HEIGHT of the box as 1. 2, and 3 
meters, respectively. 

The VMS command: $RUN MAKGEO 
executes MAKGEO and creates the box geometry. 

The VMS command: $REVIEW DRAWIN 

produces the display shown in Appendix D. 
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The REVIEWER commands; 


M 1 'TEST BOX' 

M 2 20 

M 3 30 

M 4 40 

E 

establishes the model name 'TEST BOX and X, Y, and Z rotations 
of 20, 30, and 40 degrees, respectively. 

The VMS command; $RUN ORAWIN 

executes ORAWIN and creates the input file for the program DRAW. 
The VMS command; $RUN DRAW 

produces the display, shown in figure 7, only on a TEKTRONIX 4014 
or compatible terminal. Source for the program DRAW is available 
on the file 

TOAIDE : [EXAM RLE. SOURCE ]DR AW. FOR 
and may be modified to use another graphics system. 



Figure 7. - Display From Program DRAW 
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6.0 SYSTEM LIBRARY PROCESSOR REFERENCE GUIDE 

Sections 4 and 5 introduce commands of the SYSTEM LIBRARY 
PROCESSOR used for specific examples. The purpose of this 
section is to describe each command detailing all options and any 
restrictions. These command descriptions are application- 

independent as the intention is to provide a reference guide for 

all possiblG USGS of the com in and. 

All commands are described as they apply to ATTRIBUTE 
relations (section 3.1). Unless specifically stated otherwise, 
for any descriptions or prompts, the word attribute may be 
replaced by the word parameter to render the command description 

useful for PARAMETER relations. 

All prompts appear as presented by the SYSTEM LIBRARY 
PROCESSOR with the exception of words enclosed by percent signs 
{% %). Such words represent words or phrases that depend upon 
the particular application and previous, user responses. Ml 
user responses are underlined and followed by a carriage return 

character (<CR>). 

Before executing the SYSTEM LIBRARY PROCESSOR, the SYSTEM 
library Database must reside in the current directory. To create 
the SYSTEM LIBRARY database and execute the SYSTEM LIBRARY 
PROCESSOR, see Section 4.1. 

The initial prompt; 

ENTER NUMBER OF CHARACTER /WORD FOR TARGET SYSTEM: 

4 FOR RIM ON PRIME/VAX 
10 FOR RIM ON NOS 
2 FOR SDRC/PRL 

%NUMBFR OF CHARACTERS PER W0RD%<CR_1 


establishes a conversion factor used by the "BRV" and "BF" 
comnands to retrieve/store character data from/to the database. 
The proper response depends upon the host computer system and/or 
the database management system used in execution of the REVIEWER 
and database read/write subroutines (generated by the FORMATTER). 

The SYSTEM LIBRARY command menu follows: 


SELECT OPTION: 


BR 

AR 

BT 

BF 

BS 

BRV 

BP 

PT 

LR 

PR 

X 


TO BUILD RELATIONS 

TO ADD TO AN EXISTING RELATION 

TO BUILD A TEMPLATE 

TO BUILD FORMATTER ROUTINES 

TO BUILD A SCHEMA DUMP FOR DATA BASE 

TO BUILD A REVIEWER INPUT FILE 

TO BUILD PROGRAM DESCRIPTION 

TO PRINT A TEMPLATE 

TO LIST RELATIONS 

TO PRINT A RELATION 

TO EXIT 


6.1 BR - To Build Relations 

The first step in constructing the SYSTEM LIBRARY is to 
define the relations. The "BR" command can be used at any time 
to add a relation to the SYSTEM LIBRARY. 

BR <CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE) 
%RELATI0N NAME%<CR> 


Relation names are 1 to 8 alphanumeric characters and must be 
unique. 


ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
r.OPTinN%<CR> 


A relation must be defined as PARAMETER or ATTRIBUTE type. 


ENTER RELATION DESCRIPTION (80 
%RELATION DESCR IPTION%<CR> 


CHARACTERS): 
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The relation description is presented by the REVIEWER. 

ENTER YOUR NAME (20 CHARACTERS): 

%INTEGRATOR'$ NAME%<CR> 

This entry exists only to record the name of the program 
integrator responsible for creating this relation. Following the 
prompt : 

DEFINE THE RELATION XRELATION NAME%: 

loop begins to define each PARAMETER/ATTRIBUTE. The same 

information is required for both. 

ENTER ATTRIBUTE NAME (OR <CR> WHEN D0NE)> 

XATTRIBUTE NAME%<CR> 

Names are 1 to 8 characters and may not end with the 

underscore ( ) character. These names are also used as FORTRAN 

variable names in the FORMATTER, database read/write routines. 

ENTER ATTRIBUTE TYPE> 

%I ,R .OR C%<CR> 

PARAMETER/ATTRIBUTES may be typed integer (I), real (R), or 

character (C). If character type is selected, 

ENTER NUMBER OF CHARACTERS IN STRINO 
%STRIN0 LENGTH%<CR> 

the number of characters is solicited. 

ENTER ATTRIBUTE DIMENSION (UP TO 3 SEPARATED BY C0MMAS)> 
%UP TO 3 DIMENSI0NS%<CR> 

PARAMETERS/ATTR IRUTES may be 1-, 2-, or 3-dimensional. A <CR> 

indicates a default single dimension of size one. For example, 
to dimension an attribute that is 2 x 3 x 6 enter: 

2,3,6<CR> 

The foil owi ng report 

DIMENSION =2X3X6 
indicates the selected dimension. 
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ENTER ATTRIBUTE DESCRIPTION> 

^ATTRIBUTE BE SCR I PT I ONX <CR > 

irrmriiTiTT "0 e m e a § ii ft e m ^ nt { <c r > if n/a)> 

%UNITX<CR> 

n e s c r i p 1 1 0 n s are limited to BO c h a r a c t f* r s . Units are a in a x i mu in 

of 16 characters. Both are presented by the REVIEWER. 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<£ 32 . 

The intention of including an output format is to control output 
of the P AR AME T E R /AT TR I B U TE by the REVIEWER. However, this input 
is not currently recognized by the REVIEWER, and a <CR> response 
is sufficient. 

If all inputs are correct, an affirmative response to: 

OK TO ENTER THE ATTRIBUTE %ATTRIBUTE NAME% INTO THE DATA 
BASE (Y/N) (<CR>=Y): 

%Y OR N%<CR> 

enters the PARAMETER /ATTRIBUTE into the SYSTEM LIBRARY 

PROCESSOR. A negative response disregards these entries. 

ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE) 

<CR > 

This completes the loop for defining a PARAMETER/ 

ATTRIBUTE. The loop continues to define subsequent PARAMETERS/ 

ATTRIBUTES until a <CR> is entered for: 

ENTER RELATION NAME (OR <CR> WHEN OONE)> 

<CR> 

6.2 AR - To Add To An Existing Relation 

PARAMETERS/ATTRIBUTES are added to an existing relation by 
this command. All prompts and responses are the same as the "BR" 
command. PARAMETERS/ATTRIBUTES are added to the end of the 
defined relation. As a warning, note that templates that access 
all PARAMETERS/ATTR IRUTES for an expanded relation (0 option in 
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the BT comnand described in Section 6.3) will access these new 
PARAMETERS/ATTRIBUTES in subsequent executions of the BRV and BE 
commands . 

6.3 BT - To Build A Template 

After relations are defined templates are designed to 
specify input/output from/to the database for a given 

application. 

BT<CR> 

ENTER TEMPLATE NAME (OR <CR> WHEN HONE): 

%TEMPLATE NAME%<CR> 

Template names are 1 to 8 characters in length and must be 
unique. 

ENTER 1 IF INPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 
%OPTION%<CR> 

Input templates describe data to be retrieved from the 

database. Output templates describe data to be stored into the 
database. This option determines the type of subroutine produced 

by the BF command (GETDATA_ or PUTDATA_ described in Section 
6.4). 

Following the prompt: 

IDENTIFY ALL %INPUT OR OUTPUT* RELATIONS FOR THE TEMPLATE 

loop begins to describe how the template accesses a relation. 

ENTER RELATION NAME (OR <CR> WHEN DONE ) • 

^RELATION NAME*<CR> 

E'nTER 1 FOr parameter TYPE 
OR 2 FOR ATTRIBUTE TYPE 
*0PTI0N*<CR> 

The relation name and type are entered. If the relation does not 
exist, the BR command is entered automatically to define a new 
relation. If the relation exists, an option allows review of the 
rel ati on schema : 
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THE RELATION ^RELATION NAME% IS ALREADY DEFINED AND HAS 
%NUMRER OF ATTRIBUTES% ATTRIBUTES. 

DO YOU WANT TO SEE THEM (Y/N) (<CR>=N): 


%Y OR 

N%<CR> 




An aff i rmati ve 

response displays 

the relation schema similar 

the following 

sampl e . 




ATTRIBUTE NAME 

DIMl 

DIM2 

DIM3 

TYPE NUMBER OF CHARACTERS 

A1 

2 

3 

6 

CHAR 20 

A2 




INT 

A3 

10 



REAL 


A negative response results in no such display. 

ENTER 0 IF ALL ATTRIBUTES ARE TO RE REPLACED 

OR 1 TO READ ATTRIBUTES TO BE REPLACED FROM A FILE 
OR 2 TO ENTER ATTRIBUTES TO BE REPLACED FROM TERMINAL 
%OPTION%<CR> 

All or some of the PARAMETERS/ATTRIBUTES of a relation may 

be accessed. A “0" response indicates all PARAMETERS/ATTRIBUTES 

are to be accessed. A "1" response results in a query for a file 

name containing the desired list of names (one name per 

record). A "2" response results in the prompt: 

ENTER ATTRIBUTE NAMES EACH FOLLOWED BY <CR>: 

%ATTRIBUTE NAME%<CR> WHEN DONE 

Names are then entered one per line. If a name is entered that 

does not exist in the relation, it is ignored and the prompt: 

THE ATTRIBUTE NAME %ATTRIBUTE NAME% IS NOT DEFINED FOR 
THIS RELATION. 

TRY AGAIN: 

allows input to continue with a warning. Again the option: 

THE RELATION %RELATI0N NAME% IS ALREADY DEFINED AND HAS 
%NUMBER OF ATTRIBUTES% ATTIRBUTES. 

00 YOU WANT to SEE THEM (Y/N) (<CR>=N): 

appears to provide review of the relation schema. Regardless of 

the option taken, the prompt: 

NEXT ATTRIBUTE : 

indicates that name input is to continue. 
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After all desired na^nes are entered, a <CR> ends the naming 

process and results in the report: 

YOU HAVE lOENTIFIEn %NUMBER OF ATTRIBUTESX ATTRIBUTES TO 
RE RETRIEVED 

For ATTRIBUTE type relations only, rows may be retrieved/replaced 

under conditional clauses and sorted by one or more attributes. 

ENTER NUMBER OF CONDITIONS IN THE "WHERE" CLAUSE 
OR 0 FOR NO CONDITIONS 
XNUMBER OF WHERE COND I T I0NS%<CR > 

Entering an integer greater than "0" will require the 
specification of WHERE clauses: 

FOR CONDITION XCONDITION NUMBERX ENTER: 

ATTRIBUTE NAME> 

^ATTRIBUTE NAME%<CR> 

LOGICAL OPERATOR> 

XLOGICAL OPERATOR%<CR> 

VALUE (XAtTRIBUTE TYPE%)> 

%VALUEX<CR> 


Attribute 

names must 

be 

def i ned 

for the relation. 

Logi cal 

operators 

are EQ , NE , 

LT, 

GT, LE, 

OR GE. Values must 

be of the 


same type as the attribute named. 

If more than one WHERE condition is specified, the above 


sequence is repeated for each condition, and repetitions are 
separated by the query: 

BOOLEAN OPERATOR FOR CONDITIONS XPREVIOUS CONDITIONX AND 
XNEXT CONDITION%> 

XROOLEAN OPERATOR%<CR> . 

Legal choices for the boolean operator are AND or OR. 

ENTER NUMBER OF CONDITIONS IN THE "SORT" CLAUSE 
OR 0 FOR NO CONDITIONS 
XNUMBER OF SORT C OND I T I ONSX <C R > 


Entering an integer greater than "0" requires the specification 
of sort conditions. For each sort condition, an attribute name: 


53 



FOR CONDITION %CONDITION NUHBER% ENTER; 
ATTRIBUTE NAME> 

%ATTRIBUTE NAME%<CR>] 


and sort type: 

1 FOR ASCENDING SORT OR 

2 FOR DESCENDING SORT 
%0PT10N%<CR> 


are entered. Sorting is performed by the specified sort order on 
the 1st attribute followed by the 2nd, 3rd. ..nth sort attribute. 

For ATTRIBUTE relations referenced in output templates only, 
a replacement code is required: 

ENTER REPLACEMENT CODE: 

1 - ADD ALL TUPLES AT ONCE 

2 - REPLACE ALL TUPLES AT ONCE 

3 - REPLACE ALL TUPLES EXCLUSIVELY AT ONCE 

4 - ADD TUPLES ONE AT A TIME 

5 - REPLACE TUPLES ONE AT A TIME 

6 - REPLACE TUPLES EXCLUSIVELY ONE AT A TIME 
%REPLACEMENT CODE NUMRER%<CR> 


This replacement code affects only the BF command and the 
rows are replaced in a relation as determined by following 
def i ni ti ons . 

1 - Rows are passed through the P1JTDATA_ subroutine as 

arrays and are added to the end of the current relation. 

2 - Rows are passed through the PUTDATA_ subroutine as 

arrays and replace the rows in the relation if they 

exist. If more rows are to be added than currently 

exists, new rows are added to the end of the current 
relation. 

3 - The same as 2 except if the number of rows to be 

replaced is less than the number of rows in the current 
relation, the extra existing rows are deleted. 

4, 5, and 6 - the same as 1, 2, and 3 respectively, except 
rows are passed in one at a time. Each call to a 

FORMATTER subroutine replaces one row. 

OK TO ENTER THE RELATION ^RELATION NAME% INTO THE 
TEMPLATE 

^RELATION NAME% (Y/N) (<CR>=Y): 

%Y OR N%<CR> 



An affirmative response stores the relation into the template 
within the SYSTEM LIBRARY. If mistakes have been made in the 
relation specification, a negative response disregards all 
information for this relation from the template. 

Here the loop for describing access to a relation ends with. 
ENTER RELATION NAME (OR <CR> WHEN DONE): 

At this point, another relation may be optionally specified for 

the template. When all relations are specified, a <CR> 

terminates the template definition. 

ENTER TEMPLATE NAME (OR <CR> WHEN DONE): 

Another template may be defined by entering a new template 
name. A <CR> terminates the RT command. 

6.4 BF - To Build FORMATTER Routines 

The term FORMATTER refers to conversion between database 
format and program internal format (program variables). An input 
FORMATTER routine (default name GETDATA_) retrieves data from the 
database to store in program variables. An output FORMATTER 

routine (default name PUTDATA ) retrieves data from program 

variables to store in the database. The information obtained 

from the input and output templates determines the content and 
structure of the FORMATTER GETDATA_ and PUTDATA_ rout i nes , re- 

s pect i vel y . 

R F <C R ^ 

INTER'TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "0" TO QUIT 
^TEMPLATE NAME%<CR> 

ENTER 1 IF"iNPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 
%0PTI0N%<CR> 
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ENTER %GETnATA OR PUTDATA% FILE NAME 
OR "0" TO RETURN WITHOUT WRITING A FIIE 
%FILE NAHE%<CR> 

The form of the file name prompt depends upon whether the 

template is of type input or output. The file name entered may 

he any legs! file name, including the complete directory path if 

needed. If the file exists, options are provided to overwrite 

the file or enter a new name. 

Examples :B0XIN.F0R 

TOAIDE : [EXAMPLE. S0URCE]B0X IN. FOR 

In most database systems, attribute names must be unique 

within a relation but can be duplicated in other relations. As 

the attribute names are used as FORTRAN variables in the 

FORMATTER routines, they must be unique for a selected 

template. For each set of duplicate attribute names within the 

template, the following prompts appear allowing new unique names 

to be entered: 

THE FOLLOWING RELATIONS CONTAIN OUPLICATE 
ATTRIBUTE/PARAMETER NAMES: 

NUMBER RELATION NAME 

1 %RELATI0N NAME% ^ATTRIBUTE NAME% 

2 ^relation NAME% %ATTRIBUTE NAME% 

ENTER A UNIOUE FORTRAN VARIABLE NAME FOR EACH 

OF THE ABOVE DUPLICATES (8 CHARACTERS MAXIMUM): 

1 ^RELATION NAME% %ATTRIBUTE NAME% 

%NEW NAME%<CR> 

2 XRELATION NAME% %ATTRIBUTE NAME% 

%NEW NAME%<CR> 

OK TO ENTEl^ nEw NAMES IN THE TEMPLATE? (Y/N) 

%Y OR N%<CR> 
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Attribute names may be up to 8 characters in length. As the 

character length for ANSI standard variables is only 6 

characters, an option is available to rename any attribute names 

of greater than 6 characters. 

DO YOU REQUIRE ANSI STANDARD CODE? (Y/N) (<CR>=N) 

%Y OR N%<CR> 

A negative response maintains existing attribute names. An 

affirmative response results in the following prompts allowing 

each attribute name greater than 6 characters to be renamed. 

THE FOLLOWING NAMES ARE GREATER THAN 6 CHARACTERS 
AND CANNOT REPRESENT AN ANSI STANDARD VARIABLE NAME 
ENTER A NEW NAME (6 CHARACTER MAXIMUM); 

NUMBER RELATION NAME 

1 ^RELATION NAME% %ATTRIBUTE NAMEX 

%NEW NAME%<CR> 

Variable names within programs may not match attribute names. 
Although the recommended approach is to maintain consistency 
between att ri bute names and FORMATTER variable names wherever 
possible, the variable names can be changed to match the program 
internal names. 

DO YOU WANT TO RENAME ANY OTHER PARAMETERS /ATTR I B UT E S ? 
(Y/N) (<CR>=N) 

%Y OR N%<CR> 

A negative response maintains existing attribute names. An 

affirmative response results in the following prompts allowing 

attributes to he renamed as FORMATTER variables. 

ENTER CURRENT NAME OF P AR AME TE R /ATTR I R UTE TO CHANGE 
OR "0" TO QUIT 
XATTRIBUTE NAME%<CR^ 

%NEW NAMEX<CR> _ _ 

enter Curran !'”name of parameter/attribute to change 

OR "0" to quit 

q<cr> 
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Attribute names within the database relations are never 
changed during any renaming process. Comments in the FORMATTER 
routine code link attribute names with the new FORTRAN variable 
names. Subsequent executions of the HF command for the same 

template uses these same new names without repeating the renaming 

process . 

The number of rows in a relation is virtually unlimited. 

However, as attributes are stored in the FORMATTER routines as 

arrays, a dimension must be supplied for each attribute relation 

only (does not apply to parameters). 

ENTER MAXIMUM NUMBER OF TUPLES TO BE REPLACFP FOR 
RELATION ^RELATI0N% 

%PR0GRAM'S 0IMEN$I0N%<CR> 

This information is not stored and must be reentered with 
each execution of the "BF" command for a given template. 

6.5 BS - To Build A Schema Dump For Database 

Through the RR and AR commands, descriptions of the database 
schema are defined and stored in the SYSTEM LIBRARY. Execution 
of the RS command produces a file containing the database scheina 
formatted for use in constructing the database. 

BS<CR> 

TWTlR 1 FOR RIM SCHEMA 

OR 2 FOR SDRC/PRL SCHEMA 
%0PTI0N%<CR > 

Option "1" produces a RIM command input file which must be read 
by interactive RIM (the INPUT command) to create the database 
schema. Option "2" produces FORTRAN code which must be compiled 
and linked with a special RIM to PEARL conversion library and the 
PEARL FORTRAN library to produce the database schema. 


58 



FNTFR SCHEMA DUMP FILE NAME 

OR "Q" TO RETURN WITHOUT WRITING A FILE 

‘g;FILE NAME%<CR> 

Regardless of the selected option, infonsation most be «ritten to 
a file, thus a file name must be supplied. If option "1" was 
selected, the name must be no more than 6 characters with an 
extension of .OAT. If option "2" was selected, the filename 
should have the extension .FOR. Directory location can precede 

the name. 


Examples: 

Option 1 : 

Option 2 ; 


?nAlKE;[ElAHPLE.CFG.HF.FAULnsCHEHA.nAT 

TOAIOE: [EUMPLE. CFG. DEFAULT ]PRL SOI. FOR 


If the file exists, options are provided to overwrite the file or 
enter a new name. 

cwTFR RFl ATION NAME FOR SCHEMA DUMP 

OR <Cr5 FOR COMPLETE DATABASE SCHEMA DUMP 

OR "Q" TO QUIT 
<CR> 

The schema for a single relation is dumped by entering a pre- 
defined relation name. The recommended approach is to dump the 
complete schema and create the complete database via one file. 


6.6 BRV - To Build A REVIEWER Input File 

The REVIEWER is a generic program for database review and 

modification (Section 7.0). Although data are presented in two 

standard formats (parameter and attribute), choice of data 
subsets for review is specified through the template. The 

reviewer input file represents the means of transferring the 
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template information from the SYSTEM LIBRARY to the REVIEWER. 


BRV<CR> 

inter directory location for reviewer 

OR <CR> TO CREATE A LOCAL REVIEWER F! 
%DIRECT0RY L0CATI0N%<CR> 


INPUT FILES 
LE 


When using the recommended EASIE directory structure [3] the 

REVIEWER input file is transferred to the proper location by 
entering: 


TOAIDE ; [%SYSTEMI0%. PROG] 

If not, a <CR> produces a local file. In either case, the name 
of the file is: 

^TEMPLATE NAME%.REV 


ENTER TEMPLATE NAME 

OR <CR> TO CREATE REVIEWER FILES FOR ALL TEMPLATES 
OR "O" TO QUIT ciirLMiLi 

%TEMPLATE NAME%<C> . 

REVIEWER input files may be constructed for a single template by 

entering the template name or for all defined templates by 
entering a <CR>. 

RELATION RELATION OF TEMPLATE 

K r L A ( I 0 N : 

0 - FULL MODIFICATION 

1 - MODIFY BUT CANNOT ADD ROWS 
? - CANNOT MODIFY ROWS 
%OPTIONyn<C R> 

reviewer input files contain flags for modifying attribute type 
data only that instruct the REVIEWER to modify as follows: 

0 - Allow modification of any attributes in any row 

including adding or deleting rows. 

1 - modification of any attributes in any row 

but do not allow rows to be added or deleted. 

2 - Allow only data review; no modification. 

While the flags are written, this capability is not implemented 
in the current REVIEWER. Regardless of the selected option, the 
REVIEWER acts as if the flag equals "0". These flags are not 
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saved in the SYSTEM LIBRARY and must be reentered with each 
execution of RRV. 

6-7 - BP - To Build Program Description 

The RP command is not required for i ntegrati on/i nterfaci ng 
of programs into a database system. However, if the completed 
application program is to be recognized and executed by the EASIE 
executive [4], this command must be executed for every 
appl i cati on . 

More than one FORTRAN or DCL program may be identified and 
executed as a single EASIE application. For this command, an 
application is referenced as a procedure and a program as a 
module. A procedure then consists of one or more modules to be 
executed sequentual 1 y . This is not to be confused with the EASIE 
procedure [4] which consists of one or more EASIE commands. 

BP<CR> 

ENTER NUMBER OF MODULES TO EXECUTE FOR THIS PROCEDURF > 

%NUMRE R OF MODUL E S% <CR > 

For example, if a single program is to be executed as an EASIE 
application and is integrated with the database, the response is 
" 1 " . 

If the same program is interfaced, producing a preprocessor 
to read the database and format an input file, and a post 
processor to read an output file and store data into the 
database, the response is "3". 

ENTER PROCEDURE NAME > 

XPROCEDURE NAME%<CR > 

The procedure name is the name used for all EASIE application 
commands . 
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Following this entry, a loop begins presenting a sequence of 

pronpts/responses to describe each module of the procedure: 

FOR MODULE # 1 ENTER : 

NAME > 

%M0DULE NAMEX<CR> 


The module name is the file name of the FORTRAN executable file 

or the OCL command procedure for this module. 

LOCATION (FULL DIRECTORY STRUCTURE OR 
<CR> IF SAME AS LAST MODULE) > 

%DIRECTQRY LQCAT I 0N%<CR > 

The module may be located anywhere on the disk system. 

Example: TOAIDE : [%SYSTEMID%. PROG] 

nUA0:[TESTPR0G] 

<CR> (If the program is in the current directory.) 

Names should include the complete directory path including 

1 ogical di sk name. 

ENTER 1 FOR FORTRAN PROGRAM 

OR 2 FOR COMMAND LANGUAGE PROCEDURE > 

%0PTI0N%<CR> 

The module may be either a FORTRAN program or a DCL command 
p rocedu re . 

ENTER INPUT TEMPLATE NAME > 

%INPUT TEMPLATE NAME%<CR> 

^nTEr Ouipu i'ITmplate name > 

%QUTPUT TEMPLATE NAME%<CR > 

Input and output template names are entered if they exist. If 
not applicable, a <CR> is entered. 

IS A CONFIGURATION REQUIRED? (Y/N <CR> = Y) > 

%Y OR N% <CR> 

If the module interacts with a database or requires any type of 
input/output other than from/to the interactive terminal, the 
response is Y or <CR>. Otherwise the response is N. 
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fnter name of responsible person or 

<rR> IF SWE ^S LAST MODULE > 
nNTEGRATOR'S NAME%<CR^ 

euL. e.ULs o.T, L„ recOTU LUe ua,ne oT tue pROU.,. 

’"‘''rMr’co^pletes LPe loop of «Uole Uescnl pL 1 on . The loop Is 
repeated for oacP «dnle in tPe procedure. Follo»lnp the last 

nodule description is the prompt. 

OK TO ENTER PROCEDURE INTO PROGRAM DICTNRVT (T/N <CR>-V) 

%Y OR N%<CR> 

I, all entries are correct, the response Is V. H not, 
.esponse is N and all nodule descriptions for the procedure are 

discarded. 

OK FOR NEW PROCEDURE? (Y/N <CR>=Y) > 

%Y OR N%<CR> 

MteTT;: procedure is conpletely described, the opportunity 
Ko describe another procedure is presented. An affirnative 
response repeats the procedure description process. A negative 
response ends the procedure description process. 

The procedure descriptions are stored m 
LIBRARV. For this infornation to he availahle to^ the^.L 
executive, a file. PROGRAM. PGD nust be written to 

area. (See WORKSPACE, EASIE Volume 111 .) ^ 

OK TO OUTPUT PROGRAM DATA TO .PROG AREA? 

%Y OR N%<CR> 

uiil end the BP command. An affirmative 
A negative response will end 

response will result in the prompt: 

S^prr.TORY LOCATiaN% <LRl 
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This entry «„st be the name of the PROGUFD directory used In 
system workspace. 


the 


6.8 PT - To Print A Template 

The PT command may be used at any time to print a template. 

6.9 LR - To List Relations 

The LR command may he used At 

y Je useo at any time to list all 

relations. 


6.10 PR - To Print A Relation 

The PR command may be used at any time to print a relation. 
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7.0 REVIEWER REFERENCE GUIDE 

The REVIEWER is a generic program for reading, displaying, 
modifying, and retrieving/storing selected data from/intn a 
database. The selection of data is accomplished via the REVIEWER 
input file created by the BRV command. The REVIEWER is designed 
to be executed from within the EASIE executive [4] but may be 
executed independently. To execute the REVIEWER standalone, the 
database must be in the current directory. A file named 
AinE%termi nal name%.TRM is created in the directory 
current directory and may be deleted after execution of the 


REVIEWER. 

Data are presented by the REVIEWER in categories. A 
category is a subset of a relation. A subset can be anyone of 
three options specified in the template. These options are: 
,1) some or all parameters; (2) some or all attrihutes; and (3) 
some or all rows for attribute relations. Figure 3 is an example 
of category display for parameter relations. Figure 9 is 
example of category display for attribute relations. 

Notice that for parameter relations, values, names, 

subscripts, descriptions, and units are available with each 
display. Character values, descriptions, and units may be 
truncated. For attribute relations, only values are directly 
displayed. Character values nay be truncated. Complete values, 
names, subscripts, descriptions, units, and data types are 

available with the expand (X) command. 

A command menu follows the data display for the current 

category. Once this menu is mastered, it is helpful to togg e ( 
command) the menu off allowing a larger data display on the 
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terminal screen. The REVIEWER commands are described in the 
following subsections. The commands are similar for parameter 
and attribute relations. Each command is described with 

differences pertaining to the relation type being identified as 
requ i red . 

7.1 MODIFY Command, M 

Parameter use: 

M n : modify value (n = 1 i ne# , name( subscri pt ) ,or line range) 
Attribute use: 

M r c : modify value (r = row# or range; 

c = column#,name(subscript), or range) 

The MODIFY command alters category data locally to the 

REVIEWER. The altered data may he optionally replaced in the 

database when changing categories or exiting the REVIEWER. 

Parameters are identified by names or line numbers. A line is a 

parameter or an element of a multi-dimensional parameter. 

Elements of attribute categories must be identified by both row 

number and either name or column (attribute) number. After 

entering a MODIFY command (including <CR>) the following prompt 

appears. 

ENTER NEW VALUE: 

The new value is then entered. Alternatively, the new value can 
be appended to the MODIFY command. Using this method, text 

strings with embedded blank characters must be enclosed in single 
quotes ( ' ) . 

Exampl es : 

Modify the parameter, NAME, to NEW NAME where 1 is the line 
number of NAME: 
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M KCR> 

'ENTER "NTW VALUE; 

NEW NAME<CR> 

Ml 'NEW NAME ' <CR > 

Modify the parameter NAME to NEWNAME: 

M NAME<CR> 

ENTER Nlw“ value : 

NEWNAME <CR> 

M NAME NEHNAME<C R> 

Modify row 2 column 3 to 10: 

M 2 3<CR> 

ENTER NEw VALUE; 

10<CR> 

M 2 3 10 <CR> 

Modify row 2 column name FACE(3) to 10: 

M 2 FACE{3)<CR> 

Enter "NEW value: 

10<CR> 

M 2 FACE(3) 10<CR> 

Line, row, or column numbers may be replaced by a range 
specification to modify more than one element with a single 
command. In a range specification, arguments are delimited by a 
comma(,). Arguments separated by a colon(t) indicate all numbers 
in the range (inclusively) are to be included. 

Examples: 

Modify paraineter line numbers 3, 9, 5, 6, and 7. 

M 3, 9,5 : 7 <CR> 

Modify rows 8, 2, 3, 4, 5, and 1, and columns 8,9,10.11, and 12; 
M 8. 2. 3:5,1 8:12<CR> 
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7.2 CHANGE CATEGORY Command, C 

C n : change category (n = id or name) 

When the REVIEWER is executed, the initial display is of the 
first category specified in the template. The display is changed 
to a different category by the CHANGE CATEGORY command. The new 
category is specified by the category number or name. The name 
is the relation name in the template. The number is the order of 
the relation in the template. Numbers and names can be displayed 
with the LIST CATEGORIES (CAT) command. 

Examples: 

Change to category 7 
C 7<CR> 

Change to category FACES 
C FACES<CR> 

If data have been modified in the current category, an option is 
present to replace the data in the database: 

OK TO REPLACE CHANGES? (Y) > 

An affirmative response or <CR> replaces the data. A 
negative response discards all modifications for this category. 

7.3 NEXT PAGE Command, N 

N n : next page (n = + or - pages) 

A fixed number of lines (default of 20) are displayed on the 
terminal screen (page). If the number of lines (or rows) in the 
current category exceeds this fixed number, subsequent rows are 
displayed via the NEXT PAGE command. The parameter represents a 
page number relative to the current page. 
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Exampi es : 

Lines 1:20 are initially displayed. 

N KCR> 

Displays lines 21:40. 

N 3<CR> 

Displays lines 81:100. 

N -2<C R> 

Displays lines 41:60. 

7.4 REPRINT PAGE Command, R 

R : reprint page 

The REPRINT PAGE command redisplays the current page of data 
reflecting data modifications. The display reflects 

modifications, but these are not stored in the database until the 
category is changed or the REVIEWER is exited. 

7.5 LINES PER PAGE Command, L 

L n :n line#‘s per page 

The default number of parameter lines or attribute rows is 20. 
This value is changed with the LINES PER PAGE command. 

Example: 

Display 10 lines per page. 

L 10<CR> 

7.6 EXPAND DISPLAY LENGTH Command, X 

Parameter use: 

X n : expand line# n 
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Attribute use: 

X r c : expand row# n, column# c 
Because of screen size limitations, some information is not 
available from the REVIEWER page display. For parameters, 
character values exceeding 16 characters, descriptions exceeding 
16 characters, and units exceeding 10 characters are truncated. 
For attribute data, character values exceeding 16 characters are 
truncated. Descriptions and units are not displayed. This 
information along with parameter/attribute types. character 
length when character type, and dimensions, is available through 
the EXPAND DISPLAY LENGTH command. 

Parameter Example: 

Expand parameter line number 1: 


X KCR> 


resul ts in the output : 


NAME ! TYPE ! CHARS ! 

name ! CHAR ! 80 ! 

DESCRIPTION: 

MODEL NAME 

TEST OF MAKGEO FOR FIGURE 8 


SUBSCRIPT 


! UNIT 
1 


Attribute Example: 
Expand row 3 column 2: 


X 3 2<CR> 


results in the output: 

name ! TYPE ! CHARS 


SUBSCRIPT ! UNIT 


FACE ! INT ! 

DESCRIPTION: 

FACE CONNECTIVITY 
TO 1) 

VALUE: 

5 


(NODE 


! 2 ! 

TO 2 TO 3 TO 4 (OR TO 1 IF 4=0) 


Names may be used in 


place of line or column numbers. 
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7.7 SET COLUMNS Command, S 

S : set columns to be displayed 

The SET COLUMNS command pertains only to attribute categories. 
This command may be used in either of two modes. If an integer 
parameter follows the S (separated by a space) the display is 
shifted that number of columns. Positive integers shift to the 
right and negative integers shift to the left. 

Exampl e : 

If the first six columns are displayed: 

S 6<CR> 

displays columns 7:12. Any positive integer’ greater than the 
number of remaining columns to the right results in a display of 
the last 6 columns. Any negative integer less than the number of 
remaining columns to the left results in a display of the first 6 
col umn s . 

If no integer follows the "S", the option: 

nESIGNATE THE COLUMNS OF INTEREST 
INDICATES ALL COLUMNS 
IS DELIMITER BETWEEN COLUMNS 
INDICATES A RANGE OF COLUMNS 
<CR> DESCRIBES NO CDLUMNS 

provides a review of the attributes in the current category. An 
aster isk(*) indicates all attributes are to be reviewed while 
commas and colons are used to express a range of attributes. 
(Section 7.1 provides an explanation of range.) A <CR> bypasses 
the attribute review. 

Sample output from the attribute review follows: 


COL 

! NAME 

! TYPE ! 

CHAR ! DIMENSION 

UNIT 

DESCRIPTION 

1 

! X 

! REAL ! 

0 ! 

M 

X COORDINATE 

2 

! Y 

! REAL ! 

0 ! ! 

M 

Y COORDINATE 

3 

! Z 

! REAL ! 

0 ! ! 

! M 

Z COORDINATE 
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Following the attribute review, the option 


nESIGNATE THE COLUMNS TO DISPLAY 
<CR> INDICATES ALL COLUMNS 

IS DELIMITER BETWEEN COLUMNS 
INDICATES A RANGE OF COLUMNS 

provides a selection of columns for display. A range of columns 
is specified. Alternatively, a <CR> displays the first 6 
columns. 

7.8 END COMMAND, E 

E : end and save mods 

The END command replaces any modifications for the current 
category only and terminates execution of the REVIEWER. 

7.9 QUIT Command, Q 

0 : quit without saving mods 

The QUIT command terminates the REVIEWER discarding any 
modifications made to the current category. 

7.10 HELP command, H 

H : help 

The HELP command is not implemented at the present time. 


7.11 LIST CATAGORIES Command, CAT 

CAT : list categories 


The LIST CATEGORIES 

command 

prov i des 

a 

map 

of category 

identification numbers 

(order of 

rel ati ons 

i n 

t he 

tempi ate ) 

and 

category names for the 

1 current 

tempi ate 

to 

be 

used with 

the 


CHANGE CATEGORY (C) command. 


IZ 


Example: 


CAT<CR> 

DESIGNATE THE CATEGORIES OF INTEREST 
INDICATES ALL CATEGORIES 
IS DELIMITER BETWEEN CATEGORIES 
INDICATES A RANGE OF CATEGORIES 
*<CR> 

ID CATEGORY CATEGORY DESCRIPTION 

1 MODEL MODEL INFORMATION 

2 NODES NODE POINT COORDINATES 

3 FACES CONNECTIVITY OF NODES TO FORM FACES 

7.12 DEFINE REVIEW SUBSET Command, SUB 

SUB : define review subset 

The DEFINE REVIEW SUBSET command capability is not implemented. 

7.13 TOGGLE command, T 

T : toggle menu 

By default, the menu is displayed with each page. Entering the 
TOGGLE MENU command deletes the menu from subsequent pages. 
Entering the TOGGLE MENU command again restores the menu display. 

7.14 Error Messages 

Entering an illegal range for line numbers, rows or columns 
results in the output; 

ERROR IN RANGE SPECIFICATION - TRY AGAIN: 

NOT A VALID COMMAND, PLEASE MODIFY COMMAND 

and the command is ignored. 

Entering a range of line numbers or rows of different types 

for modification results in the output; 

ERROR - ALL %PARAMETERS OR ATTRIBUTES% IN RANGE ARE NOT 
OF THE SAME TYPE 

NOT A VALID COMMAND, PLEASE MODIFY COMMAND 
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and the command is ignored. 

Entering any other illegal command results in the output 
NOT A VALID COMMAND, PLEASE MODIFY COMMAND 
and the command is ignored. 
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MODEL INFORMATION 


CATEGORY 


1 : 


MODEL 


L ! PRESENT VALUE ! NAME ! SUBSCRIPT ! DESCRIPTION ! UNITS 


1 ! IE SI OF MAKGEO K ! NAME ! 

2 ! 20.0000000 ! ROTATION ! 

3 ! 30.0000000 ! ! 

4 ! 40.0000000 ! ! 


! MODE! NAME ! 

1 ! MODEL X,Y,Z ROTA ! DEGREES 

2 ! ! 

3 ! ! 


M n : modify value (n = line#,name(subscript),or line range) 

C n : change category (n = id or name) 

N n : next page (n = + or - pages) 

R ; reprint page, L n : n line#'s per page, X n : expand line# n 
E : end and save mods, Q : quit without saving mods, H : help 
CAT : list categories, SUB : define review subset, T : toggle menu 
EDIT: 

> 

Figure 8. - REVIEWER DISPLAY OF PARAMETER DATA 


CATEGORY 3: FACES 

CONNECTIVITY OF NODES TO FORM FACES 


NAME 

INDEX 

1 

! 

FACE ! 

1 ! 

FACE ! 

2 ! 

FACE ! 

3 ! 

FACE 

4 

COL 

j 

1 ! 

2 ! 

3 ! 

4 

ROW : 


1! 

1 ! 

2 ! 

3 ! 

4 


2! 

2 ! 

6 ! 

7 ! 

3 


3! 

6 ! 

5 ! 

8 ! 

7 


4! 

5 ! 

1 ! 

4 ! 

8 


5! 

4 ! 

3 ! 

7 ! 

8 


6! 

5 ! 

6 ! 

2 ! 

1 


M r c : modify value(r= row# or range; c= column#, name(subscript), or range) 
C n : change category (n = id or name) 

N n : next page (n = + or - pages) 

k : r 0 print paQB, L n : n rows per p390> X r c : expand row# n, column# c 
S : set columns to be displayed 

E : end and save mods, Q : quit without saving mods, H : help 

CAT : list categories, SUB : define review subset, T : toggle menu 

EDIT: 

> 

Figure 9. - REVIEWER Display Of Attribute Data 
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USE OF THE SYSTEM LIBRARY PROCESSOR FOR THE COMPLEX EXAMPLE 


$Rl)NI)ICT<CR> 

ElrfElTliUMBER nr CHARACTER/WORO for target SYSTEM; 
4 FOR RIM ON PRIME/VAX 
10 FOR RIM ON NOS 
2 FOR SORC/PRL 

4<CR> 


SELECT OPTION: 

BR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BF - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

RRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BR<CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE); 
NODES<CR> 


ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR> 


ENTER RELATION DESCRIPTION (80 CHARACTERS): 
NODE POINT COORDINATES<CR> 


ENTER YOUR NAME (20 CHARACTERS): 
JOHN DOE<CR> 


DEFINE THE RELATION NODES : 

ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 
X<CR> 
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ENTER ATTRIBUTE TYPE> 
R<CR> 


ENTER ATTRIBUTE DIMENSION (UP TO 3 SEPARATED BY COMHAS)> 
KCR> 


DIMENSION = 1 

ENTER ATTRIBUTE DESCRIPTION> 

X COORDINATE <C R> 

ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 

M<CR> 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<CR> 

OK TO ENTER THE ATTRIBUTE X INTO THE DATA BASE (Y/N) (<CR>=N) 

Y<CR> 


ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 

Y<CR> 

ENTER ATTRIBUTE TYPE> 

R<CR> 

ENTER ATTRIBUTE DIMENSION (UP TO 3 SEPARATED BY COMMAS)> 

KCR> 

DIMENSION = 1 

ENTER ATTRIBUTE DESCRIPTION> 

Y COORD I NATE <C R> 

ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 

M<CR> 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<CR> 

OK TO ENTER THE ATTRIBUTE Y INTO THE DATA BASE (Y/N) (<CR>=N) 

Y<CR> 


ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 

Z<CR> 

ENTER ATTRIBUTE TYPE> 

R<CR> 

ENTER ATTRIBUTE DIMENSION (UP TO 3 SEPARATED BY COMMAS)> 
KCR> 
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niMFNSION = 1 

ENTER ATTRIBUTE DESCRIPTinN> 

z__cnnRnj Nj^ excr>. 

ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 

M<CR> 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<CR> 

OK TO ENTER THE ATTRIBUTE Z INTO THE DATA BASE (Y/N) «CR>=N): 

Y<CR> 


ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 
<CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE): 
FACES<CR> 


ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR> 


ENTER RELATION DESCRIPTION (80 CHARACTERS): 
rONNFCTIVITY OF NODES TO FORM FACF.S<CR^ 


DEFINE THE RELATION FACES : 


ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 

FACE<CR> 

ENTER ATTRIBUTE TYPE> 

KCR> 

ENTER ATTRIBUTE DIMENSION (UP TO 3 SEPARATED BY COMMAS)> 
4< CR> 


DIMENSION = 4 

ENTER ATTRIBUTE DESCRIPTION> 
face connectivity (NODE 1 TO 


2 TO 3 TO 4 (OR TO 1 IF 4-0) TO 1)<CR> 


ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 
<CR> 


ENTER OUTPUT FORMAT (<CR> IF N/A)> 
<CR> 
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?<CR> attribute face into the data base (Y/N) {<CR>=N) 


ENTER ATTRIBUTE NAME (OR <CR> WHEN DONE)> 


ENTER RELATION NAME (OR <CR> WHEN DONE) 
MODEL <CR> ’ 

ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
KCR> 


ENTER RELATION DESCRIPTION 
MODEL INF0RMAT10N<CR> 


(80 CHARACTERS): 


DEFINE THE RELATION MODEL 


ENTER PARAMETER NAME (OR <CR> WHEN DONE)> 
NAME<CR> ^ 


ENTER PARAMETER TYPE> 
C<CR> 


ENTER NUMBER OF CHARACTERS IN STRINO 
80<CR> 


ENTER PARAMETER DIMENSION (UP TO 3 SEPARATED BY COMMAS)> 

1 sL K / 


DIMENSION = 1 

ENTER PARAMETER DESCRIPTION> 

MODEL NAME<CR> 

ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 

<CR> ’ 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<CR > 

Y<CR> parameter NAME INTO THE DATA BASE (Y/N) (<CR>=N): 


ENTER PARAMETER NAME (OR <CR> WHEN DONE)> 
ROTATION<CR> 


ENTER PARAMETER TYPE> 
R<CR> 
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ENTER PARAMETER DIMENSION (UP TO 3 SEPARATED BY COMMAS)> 

3<CR> 

DIMENSION = 3 

ENTER PARAMETER DESCRIPTION> 

MODEL X>Y,Z ROTATIONS RESPECT I V ELY<CR> 

ENTER UNIT OF MEASUREMENT (<CR> IF N/A)> 

DEGREES<CR> 

ENTER OUTPUT FORMAT (<CR> IF N/A)> 

<CR> 

OK TO ENTER THE PARAMETER ROTATION INTO THE DATA BASE (Y/N) (<CR>=N) 
Y<CR> 

ENTER PARAMETER NAME (OR <CR> WHEN OONE)> 

<CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE): 
<CR> 


SELECT OPTION: 

RR - TO RUILO RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILO A TEMPLATE 

BF - TO RUILO FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA RASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

RP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BT<CR> 


ENTER TEMPLATE NAME (OR <CR> WHEN DONE): 
MAKGEOIN<CR> 

ENTER 1 IF INPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 
KCR> 

IDENTIFY ALL INPUT RELATIONS FOR THE TEMPLATE 
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ENTER RELATION NAME (OR <CR> WHEN DONE): 
DIMEN<CR> 


ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
KCR> 

THE RELATION DIMEN IS ALREADY DEFINED AND HAS 4 PARAMETERS. 

DO YOU WANT TO SEE THEM (Y/N) (<CR>=N): 

N<CR> 

ENTER 0 IF ALL PARAMETERS ARE TO BE RETRIEVED 

OR 1 TO READ PARAMETERS TO BE RETRIEVED FROM A FILE 
OR 2 TO ENTER PARAMETERS TO BE RETRIEVED FROM THE TERMINAL 
2<CR> 

ENTER PARAMETER NAMES EACH FOLLOWED BY <CR>: 

(PARAMETER NAME=<CR> WHEN DONE) 

LENGTH<CR> 

WIOTH<CR> 

heiGhT<CR> 

YOU HAVE IDENTIFIED 3 PARAMETERS TO BE RETRIEVED 

OK TO ENTER THE RELATION DIMEN INTO THE TEMPLATE MAKGEOIN (Y/N) (<CR>=N): 
Y<CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE): 
<CR> 

ENTER TEMPLATE NAME (OR <CR> WHEN DONE): 
MAKGEOOT<CR> 


ENTER 1 IF INPUT TEMPLATE 
OR 2 IF OUTPUT TEMPLATE 
2<CR> 

IDENTIFY ALL OUTPUT RELATIONS FOR THE TEMPLATE 


ENTER RELATION NAME (OR <CR> WHEN DONE): 
NODES<CR> 

ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR> 
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THE RELATION NODES IS ALREADY DEFINED AND HAS 
DO YOU WANT TO SEE THEM (Y/N) (<CR>=N); 

N<CR> 


ATTRIBUTES. 


FNTFR 0 IF ALl ATTRIBUTES ARE TO BE REPLACED 

DR 1 TO READ ATTRIBUTES TD BE REPLACED FROM A FILE 
Z 2 TO TnTER ATTRIBUTES TO BE REPLACED FROM THE TERMINAL 


0<CR> 


ENTER NUMBER OF CONDITIONS IN THE "WHERE" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 

ENTER NUMBER OF CONDITIONS IN THE "SORT" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 


ENTER REPLACEMENT CODE: 


1 

2 

3 

4 

5 

6 


ADD ALL TUPLES AT ONCE 

REPLACE ALL TUPLES AT ONCE 

REPLACE ALL TUPLES EXCLUSIVELY AT ONCE 

ADD TUPLES ONE AT A TIME 

REPLACE TUPLES ONE AT A TIME 

REPLACE TUPLES EXCLUSIVELY ONE AT A TIME 


3<CR> 


OK TO ENTER THE RELATION NODES INTO THE TEMPLATE MAKGEOOT (Y/N) (<CR>=N) 
Y<CR> 


ENTER RELATION NAME (OR <CR> WHEN DONE); 
FACES <CR> 


ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR2 

THE RELATION FACES IS ALREADY DEFINED AND HAS 
DO YOU WANT TO SEE THEM (Y/N) (<CR>-N); 

N<CR> 


1 ATTRIBUTES. 


ENTER 0 IF ALL ATTRIBUTES ARE TO BE REPLACED cti c 

OR 1 TO READ ATTRIBUTES TO BE REPLACED FROM A FILE 
OR 2 TO ENTER ATTRIBUTES TO BE REPLACED FROM THE TERMINAL 

0<CR> 


ENTER NUMBER OF CONDITIONS IN THE "WHERE CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 
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ENTER NUMBER OF CONDITIONS IN THE "SORT" CLAIJSF 
OR 0 FOR NO CONDITIONS 
0<CR> 

ENTER REPLACEMENT CODE: 

1 - ADD ALL TUPLES AT ONCE 

2 - REPLACE ALL TUPLES AT ONCE 

3 - REPLACE ALL TUPLES EXCLUSIVELY AT ONCE 

4 - ADD TUPLES ONE AT A TIME 

5 - REPLACE TUPLES ONE AT A TIME 

6 - REPLACE TUPLES EXCLUSIVELY ONE AT A TIME 


?<CR> “ELATION FACES INTO THE TEMPLATE MAKGEOOT (Y/N) «CR>.N) 


ENTER RELATION NAME (OR <CR> WHEN DONE)- 
<CR> 

ENTER TEMPLATE NAME (OR <CR> WHEN DONE)- 
DRAWIN<CR> 

ENTER 1 IF INPUT TEMPLATE 
OR P IF OUTPUT TEMPLATE 
KCR> 


IDENTIFY ALL INPUT RELATIONS FOR THE TEMPLATE 


ENTER RELATION NAME (OR <CR> WHEN DONE 
MODEL<CR> 

ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
KCR> 


THE RELATION MODEL IS ALREADY DEFINED AND HAS 
DO YOU WANT TO SEE THEM (Y/N) (<CR>=N)- 
N<CR> '' 


2 PARAMETERS. 


ENTER 0 IF ALL PARAMETERS ARE TO BE RETRIEVED 

OR 1 TO READ PARAMETERS TO RE RETRIEVED FROM A FILE 

OR 2 TO ENTER PARAMETERS TO BE RETRIEVED FROM THE TERMINAL 


Y<CR> relation MODEL INTO THE TEMPLATE DRAWIN (Y/N) (<CR>=N); 


ENTER RELATION NAME (OR <CR> WHEN DONE) 
NODES<CR> 
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ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR> 


THE RELATION NODES IS ALREADY DEFINED AND HAS 

DO YOU WANT TO SEE THEM (Y/N) (<CR>=N)- 

N<CR> 


ATTRIBUTES. 


ENTER 0 IF ALL ATTRIBUTES ARE TO BE RETRIEVED 

OR 1 TO READ ATTRIBUTES TO BE RETRIEVED FROM A FILE 

OR 2 TO ENTER ATTRIBUTES TO BE RETRIEVED FROM THE TERMINAL 


ENTER NUMBER OF CONDITIONS IN THE "WHERE" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 


ENTER NUMBER OF CONDITIONS IN THE "SORT" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 

Y^rR> relation nodes into THE TEMPLATE DRAWIN (Y/N) (<CR>=N 


ENTER RELATION NAME (OR <CR> WHEN DONE ) • 
FACES<CR> 

ENTER 1 FOR PARAMETER TYPE 
OR 2 FOR ATTRIBUTE TYPE 
2<CR> 


THE RELATION FACES IS ALREADY DEFINED AND HAS 

DO YOU WANT TO SEE THEM (Y/N) (<CR>=N)- 

N<CR> 


1 ATTRIBUTES. 


ENTER 0 IF ALL ATTRIBUTES ARE TO BE RETRIEVED 

OR 1 TO READ ATTRIBUTES TO BE RETRIEVED FROM A FILE 

OR 2 TO ENTER ATTRIBUTES TO BE RETRIEVED FROM THE TERMINAL 


ENTER NUMBER OF CONDITIONS IN THE "WHERE" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 


ENTER NUMBER OF CONDITIONS IN THE "SORT" CLAUSE 
OR 0 FOR NO CONDITIONS 
0<CR> 


Y<CR> relation faces INTO THE TEMPLATE DRAWIN (Y/N) (<CR>=N) 
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ENTER RELATION NAME (OR <CR> WHEN HONE): 

enter TEMPLATl NAME (OR <CR> WHEN DONt 
<CR> 


SELECT OPTION: 

BR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BE - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BS<CR> 


ENTER 1 FOR RIM SCHEMA 

OR 2 FOR SDRC/PRL SCHEMA 

KCR> 


ENTER SCHEMA DUMP FILE NAME 

OR "0" TO RETURN WITHOUT WRITING A F 

SCHEMA. DAT<CR> 


LE 


ENTER RELATION NAME EOR SCHEMA DUMP 

OR <CR> FOR COMPLETE DATABASE SCHEMA DUMP 

OR "0" TO QUIT 
<CR> 


SELECT OPTION 


BR 
AR 
BT 
BF 
BS 
BRV 
BP 
PT 
LR 
PR 
X 

BF<CR> 


TO BUILD RELATIONS 

TO ADD TO AN EXISTING RELATION 

TO BUILD A TEMPLATE 

TO BUILD FORMATTER ROUTINES 

TO BUIID A SCHEMA DUMP EOR DATA BASE 

TO BUILD A REVIEWER INPUT FILE 

TO BUILD PROGRAM DESCRIPTION 

TO PRINT A TEMPLATE 

TO LIST RELATIONS 

TO PRINT A RELATION 

TO EXIT 
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rNTER TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "Q" TO QUIT 
MAKGEOIN<CR> 

ENTER GETOATA FILE NAME 

OR "Q" TO RETURN WITHOUT WRITING A FILE 

MAKGEOIN.FOR<CR> 

DO YOU REQUIRE ANSI STANDARD CODE? (Y/N) (<CR>=N) 

N<CR> 

DO YOU WANT TO RENAME ANY OTHER PARAMETERS/ATTRIBUTES? (Y/N) (<CR>-N) 
N<CR> 


SELECT OPTION: 

RR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO RUILD A TEMPLATE 

RE - TO BUILD FORMATTER ROUTINES 

RS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

RF<CR> 

ENTER TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "0" TO QUIT 
MAK6EOOT<CR> 


ENTER PUTDATA FILE NAME 

OR "0" TO RETURN WITHOUT WRITING A FILE 

MAK GEOOT.F O R<CR> 

DO YOU REQUIRE ANSI STANDARD CODE? (Y/N) (<CR>=N) 

N<CR> 

DO YOU WANT TO RENAME ANY OTHER PARAMETERS/ATTRIBUTES? (Y/N) (<CR>=N) 
N<CR> 


ENTER 

8<CR> 

MAXIMUM 

NUMBER 

OF 

TUPLES 

TO 

BE 

REPLACED 

FOR 

RELATION 

NODES 

ENTER 

G<CR> 

MAXIMUM 

NUMBER 

OF 

TUPLES 

TO 

RE 

REPLACED 

FOR 

RELATION 

FACES 
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SELECT OPTION: 

BR - TO BIJILO RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BE - TO BUILD FORMATTER ROUTINES 

BS - TO BUILn A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BF<CR> 


ENTER TEMPLATE NAME 
OR <CR> FOR ALL RELATIONS 
OR "Q" TO QUIT 
DRAWIN<CR> 

ENTER GETDATA FILE NAME 

OR "Q” TO RETURN WITHOUT WRITING A FILE 

nRAWIN.FOR<CR> 

DO YOU REQUIRE ANSI STANDARD CODE? (Y/N) (<CR>=N) 

N<CR> 

no YOU WANT TO RENAME ANY OTHER PARAMETERS/A TTRIRUTES? (Y/N) (<CR>=N) 
jKC^ 

ENTER MAXIMUM NUMBEP OF TUPLES TO BE RETRIEVED FOR RELATION NODES 
10 0<CR> 

ENTER MAXIMUM NUMBER OF TUPLES TO BE RETRIEVED FOR RELATION FACES 
100<CR> 


SELECT OPTION: 

BR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BF - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BRV<CR> 
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SOURCE CODE FILES 


THE PROGRAM MAKGEO AS CONTAINED IN THE FILE MAKGEO.FOR: 


PROGRAM MAkGEO 
C 

COMMON /INDIMEN/ LENGTH, WIDTH, HEIGHT 
REAL LENGTH 

COMMON /OUTGEO/ X(8) , Y(8) ,Z(8) ,NG,FACE(4,6) ,NF 
INTEGER FACE 
C 

CALL GETDATA_ 

C 

NG = 8 
NF = 6 

HL = LENGTH/2. 

HW = WIDTH/2. 

HH = HEIGHT/2. 

C 

X(l) = -HL 
Y(l) - -HH 
Z(l) = -HW 
X{2) = HL 
Y(2) = -HH 
Z(2) = -HW 
X(3) = HL 
Y(3) = HH 
Z(3) = -HW 
X(4) -- -HL 
Y(4) = HH 
Z(4) = -HW 
X(5) = -HL 
Y(5) = -HH 
Z(5) = HW 
X(6) = HL 
Y(6) = -HH 
Z(6) = HW 
X(7) = HL 
Y(7) = HH 
Z(7) = HW 
X(8) = -HL 
Y(8) = HH 
Z(8) = HW 
FACE(1,1) = 1 
FACE(2,1) = 2 
FACE{3,1) = 3 
FACE(4,1) = 4 
FACE(1,2) = 2 
FACE(2,2) = 6 
FACE(3,2) = 7 
FACE(4,2) = 3 
FACE(1,3) = 6 
FACE(2,3) = 5 
FACE(3,3) = 8 
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FACE(4,3) = 7 
FACE(1,4) = 5 
FACE(2,4) = 1 
FACE(3,4) = 4 
FACE(4,4) = 8 
FACE(1,5) = 4 
FACE(2,5) = 3 
FACE (3, 5) = 7 
FACE(4,5) = 8 
FACE(1,6) = 5 
FACE(2,6) = 6 
FACE(3,6) = 2 
FACE(4,6) = 1 
C 

CALL PUTDATA 
C “ 

END 
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THE SUBROUTINE GETDATA_ FOR USE WITHIN MAKGEOIN.FOR 


SUBROUTINE GETDATA_ 

COMMON /0BNAME_/ DBASE_,DBOPN_ 

REAL*8 DBASE 
logical DBOPl^ 

C*** THE PARAMETERS FOR THE RELATION DIMEN ARE 
REAL LENGTH 
REAL WIDTH 
REAL HEIGHT 

load REQUIRED COMMON BLOCKS HERE; 

INCLUDE 'MAKGEOIN. COMMON/LIST' 

DBASE_ = (8HDATADB ) 

CALL R1001_(LENGTH, WIDTH, HEIGHT) 

MAKE ANY NECESSARY RE-ASSIGNMENTS HERE: 

INCLUDE 'MAKGEOIN. ASSIGN/LIST' 

RETURN 
C 

END 
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THE SUBROUTINE PUTDATA_ FOR USE WITHIN MAKGEOOT.FOR 

SUBROUTINE PUTDATA 
C - 

COMMON /DBNAME / DBASE .DBOPN 
REAL*8 DBASE ~ ~ “ 

LOGICAL DBOP¥ 

C 

^*** FOR THE RELATION NODES ARE- 

REAL X ( 8) 

REAL Y 8 

REAL Z ( 8 

'*** "?NTEG™'®FA« 

c 

C LOAD REQUIRED COMMON BLOCKS HERE: 

INCLUDE 'MAKGEOOT.COMMON/LIST' 

DBASE_ = (8HDATADB ) 

0 

C MAKE ANY NECESSARY RE-ASSIGNMENTS HERE: 

C INCLUDE ’MAKGEOOT. ASSIGN/LIST* 

c 

CALL W1001_(X,Y,Z,N001 ) 

^ CALL W1002_(FACE,N002_7 

RETURN 

C 

END 


CONTENTS OF THE FILE MAKGEO.COM 

$FOR MAKGEO.FOR 
$FOR MAKGEOIN.FOR 
$FOR MAKGEOOT.FOR 
SLINK MAKGEO.OBJ - 
+MAKGEOIN.OBJ - 
-^MAKGEOOT.OBJ - 
+LOADRIM/LIB 
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the file ORAWIN.FnR MODIFIED AS NEEDED 


c SUBROUTINE GETDATA_ 

^ COMMON /DBNAME_/ DBASE_,DBOPN_ 

REAL*8 DBASE 
logical DB0PN_ 


C*** THE PARAMETERS FOR THE RELATION MODEL 
THARACTER* 80 NAME 

C... TrURIBrErjrTHE REGION NODES 


REAL 

REAL 

REAL 


100) 

100 ) 

100 ) 


ncAi 7 \ / 

C*.* th“aTTRI6UTES for the relation FACES 
inteafr FACE ' '*• 


c 

c 

c 

c 

c 


load required common blocks HERE: 


INCLUDE 'DRAWIN. COMMON/LIST' 
DBASE = (8HDATADR ) 


CALL RlOOl (NAME, ROTATION) 
CALL R1002I(X.Y.Z,N002 ) 
r.ALL R1003 (FACE ,N003_J 


C MAKE ANY NECESSARY RE-ASSIGNMENTS HERE 
INCLUDE 'DRAWIN. ASSIGN/LIST' 


C 

C RETURN 
C 

END 


ARE: 


ARE: 


ARE: 
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C 

c 


CONTENTS OF THE FILE DRAWIN. ASSIGN: 
CONVERT ROTATION FROM DEGREES TO RADIANS: 

10 CONT?nSJ^°^^^^ " ROTATION(I) * DEGRAD 
WRITE DATA TO INPUT FILE 'DRAW.DAT': 

WRITE(8/'(Ar'nAMr^' 

aoslfsY'"®''’ 


CONTENTS OF THE FILE DRAWIN.COM; 

SFOR DRAWIN. for 

Slink drawin.obj - 
+L0ADRIM/LIB 
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TEMPLATE MAKGEOIN 


TO ESTABLISH VALUES FOR LENGTH, WIDTH AND HEIGHT 


SREVIEW MAKGEOIN<CR> 


BOX DIMENSIONS 


CATEGORY 1: DIMEN 


L 


PRESENT VALUE 


name ! SUBSCRIPT ! DESCRIPTION ! UNITS 


0.0000000 ! LENGTH ! 
0.0000000 ! WIDTH ! 
0.0000000 ! HEIGHT ! 


! BOX LENGTH ! M 

! BOX WIDTH ! M 

! BOX HEIGHT ! M 


M n 
C n 
N n 
R : 
E : 
CAT 


: modify value (n = 1 i ne#,name{subscri pt) ,or line range) 

: change category (n = id or name) 

: next page (n = + .or - pages) n 

reprint page. L n : n line#‘s per page, X n : expand line# n 

end and save mods. 0 : quit without saving mods. H ; he p 
: list categories, SUB ; define review subset, T . toggle menu 


EDIT: 

> M LENGTH KCR> 

> M WIDTH 

> M HEIGHT 

> R<Cft> 

CATEGORY 1: OIMEN 

BOX DIMENSIONS 


L ! 

1 ! 
2 ! 
3 ! 


PRESENT VALUE ! NAME 


SUBSCRIPT 1 DESCRIPTION ! UNITS 


1.0000000 ! LENGTH ! 

2.0000000 ! WIDTH ! 

3.0000000 ! HEIGHT ! 


! BOX LENGTH ! M 

! BOX WIDTH ! M 

! BOX HEIGHT ! M 


M n 
C n 
N n 
R : 
E : 
CAT 


: modify value (n = 1 ine#,name(subscript).or line range) 

: change category (n = id or name) 

\S~l\er pa,e,.X n : expand Une, n 
"lisJ^rtrgorfes; SUB -'ilfin^rf^ : toggle menu 


EDIT: 

> E<CR> 
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TEMPLATE DRAWIN 


TO ESTABLISH VALUES FOR NAME AND ROTATIONS 


$REVIEW DRAWIN<CR> 


MODEL 

INFORMATION 

CATEGORY 1: 

MODEL 



L ! 

PRESENT VALUE 

! NAME ! SUBSCRIPT 

! DESCRIPTION 


! UNITS 

1 ! 
2 ! 

3 ! 

4 ! 

0.0000000 

0.0000000 

0.0000000 

! NAME ! 

! ROTATION ! 1 

! ! 2 

! ! 3 

! MODEL NAME 
! MODEL X,Y,Z 
! 

1 

ROTA 

1 

! DFGREES 

I 

1 

M n : modify value (n 
C n : change category 
N n : next page (n = + 
R : reprint page, L n 
E : end and save mods, 
CAT : list categories, 
EDIT: 

> M 1 'TEST B0X'<CR> 

= line#,nane(subscript),or line range) 

(n = id or name) 
or - pages) 

n line#'s per page, X n : expand line# n 
Q : quit without saving mods, H : help 
SUB : define review subset, T : toggle menu 


> M 2 20<CR> 

> R'TT(T<Cf!> 

> Trrw<c]?y 

> R<CR> 





MODEL 

INFORMATION 

CATEGORY 1: 

MODEL 



L ! 

PRESENT VALUE 

! NAME ! SUBSCRIPT 

! DESCRIPTION 


! UNITS 

1 ! 
2 ! 

3 ! 

4 ! 

'TEST BOX' 

20.0000000 

30.0000000 

40.0000000 

! NAME ! 

! ROTATION ! 1 

! ! 2 

! ! 3 

! MODEL NAME 
! MODEL X,Y,Z 

ROTA 

j 

! DEGREES 

f 

j 


M n : nodify value (n = 1 ine#,name(subscript) ,or line range) 

C n : change category (n = id or name) 

N n : next page (n = + or - pages) 

R : reprint page, L n : n line#'s per page, X n : expand line# n 
E : end and save mods, Q : quit without saving mods, H : help 
CAT : list categories, SUB : define review subset, T : toggle menu 
EDIT: 

> E<CR> 

$ 
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BUILD_EASIE 

Version 1.0 for VAX/VMS Running EASIE With RIM 

Should ha.e a good knowledge of EUSIE before attempting to 
use this program) 

BUUP_EAS1E is a utility program designed to aid in the 
installation of programs into the Environment for Application 
software Integration and Execution (EASiE)-. When the 

construction of large numhers of relations would make the 
interactive processor RUNDICT tedious to use, BUILD_EASIE 
provides an easy-to-use alternative file interface. The user 
creates a data file called EASIE.DAT (described in the following 
section) which contains the relation and template data for one or 

„re programs t o he i nsta 1 1 ed i n to EASIE . BU 1 LD_EASIE provides 
commands that operate on EASIE.DAT and then prompts tor the 

uesired relations and templates to be created. The BUItn_EASIE 
program generates a VAX/VMS command procedure called EASIE. COM 
which includes the calls to RUNDICT and the answers to all of its 
prompts. The Ion, series of prompts in RUNDICT need not he 

answered interactively and the database structure can be easily 
maintained in EASIE.DAT. Changing the database structure 

requires only simple editing of EASIE.DAT and a re-execution of 
BUILD_EASIE and EAS1E.COM. Currently eUlLD_EASlE supports only 
PARAMETER type relations. 

EASIE.COM creates the relations, templates. FORMATTER 
routines (GETDATA_/RUTDATAJ , the REVIEWER files, the database 
schema, and the three RIM database files. The FORMATTER 

routines are created in files with the template name and a .FOR 
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extension. REV,E«R files have the template na« with a .REV 
extension. The data base schema is created in SCHEHA.DAT. 

euUD_EASIE also creates for each input template a command 
procedure called a reviewer loader. The reviewer loader calls 
the EASIE REVIEWER and loads values into the database for each 
variable contained in the template. Editing the reviewer loader 
command procedure supplies the values for the variables in the 
template. Reviewer loaders are created in files with the input 
template name and a .COM extension. These files provide a method 

initializing all variables to values representative of some 
basel ine check case. 


The data file can be sorted, by variable name, by typing the 
sort command provided in BUILD_EASIE. The sorted data file is 
not used by BUUD_EASIE hut is intended to be a reference tool. 

BUUD_EASIE is run at the terminal by typing 
RUN BUILO_EASIE. The first prompt reguires the EASIE data file 
name. A carriage return will assign the default file name of 
EASIE.DAT. The syntax of the three BUItn_EASIE commands is then 
displayed. The three commands are: ( 1 ) "R <relation name>" to 

build relations; (2) »T ctemplate names- to build templates; and. 

(3) to sort EASIE. OAT. A simple carriage return will end the 

execution of BUILD FASIF fa<:if rnM 

EASIE.COM and any reviewer loaders 

will reside m the current directory. EASIE.COM can now be 

executed at the terminal or in batch mode. 
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Creating the EASIE Data File. 

EASIE.OAT is a formatted file that contains the data for an 
unlimited number of relations and templates. Template names must 
bepin with the letter 0 for output templates or the letter I for 
input templates. The format of EASIE. DhT is as follows: 


* Rel ati on_name Rel ati on_descn pti on 

Date User_name 
Va ri abl e_name Data_type 

t em p1 at e ame s . . . 

Va r i abl e_name Data_type 
t eiti pi a t e ame s . • • 


dimensi ons Units 
dimensions Units 


Format Description 
Format Description 


* Rel ati on_n ame Rel ati on_descri pti on 

Date User_name imitc 

Variable_name Data_type dimensions Units 

tempi ate_names . . . 


Format Description 


Al, data must appear in the proper columns for BUILD_EASIE to 
work properly. All variables listed below a relation name are 
placed in that relation until a new relation name is declared or 
the end of the file is reached. The template names refer to the 
variable listed on the line above them. All templates in which 
the variable will be included must be listed. No field in the 
data file may begin with the $ character. The column and field 
specifications for each piece of information is as follows: 
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EASIE Data Item 

Relation name 
Relation Description 
Date 

User Name 
Variable Name 
Data Type 
Dimensions 


Units 

Format 

Variable Description 
Template Names 


Comments 


Beginning Column # 


* in column #2 must be present 
40 characters maximum 

Date relation is created (not used by EASIE) 

Name of programmer 

7 characters maximum 

Must be R, C, D, or I 

Up to 3 separated by commas with no 
embedded spaces. For character type the 
length must appear first, followed by a 
space then the dimensions 

Anything, use "+" for no units 

FORTRAN output format, or "+" for default 

40 characters maximum 

Any number separated by blanks, begin 
with I or 0 


4 

13 

4 

13 

2 

10 

12 

25 

42 

59 

4 


Example Run of BUILD_EASIE: 

The following is a sample scenerio for installing a program 
into EASIE using BUUD_EASIE. Terminal input and output is shown 
in small type with the user inputs in bold face. 

We begin by displaying our default directory which contains 
the BUILD_EASIE executable and the EASIE.DAT file. 


$ DIR 

Directory DISK:[FASIE] 
BI)ILD_EASIE.EXE;1 EASIE.DAT;! 
Total of 2 fi 1 es. 


E-4 



APPENDIX E 


$ TYPE EASIE.DAT 


* REL 1 RELATION 

FOR 

TEST PROGRAM 



01/01/88 JOHN SMITH 




XXX R 1 

ITEMP OTEMP 


FEET 

+ 

DISTANCE TO SATELLITE 

YYY I 2.3,2 

ITEMP OTEMP 


INCHES 

15 

SIZE OF PARTS 

III R 5,6 

OTEMP ITARLE 
* REL 2 RELATION 

03/IT3/88 JOE BLOW 

NO. 

METERS 

2 

+ 

COORDINATES 

DESCR C 80 1 
OTEMP ITARLE 


+ 

+ 

PROGRAM DESCRIPTION. 

VOL R 1 

OTEMP 


M**3 

- 1 - 

VOLUME OF OBJECT 

COUNT I 1 
ITEMP 


+ 

13 

NUMBER OF PARTS 


This EASIE.DAT file contains the data for two relations and 
three templates. Relation REL_1 contains the variables XXX, 
YYY, and 111. Relation REL_2 contains the variables DESCR, VOL, 
and COUNT. Input template ITEMP contains the variables XXX, YYY, 
DESCR, and COUNT. Output template OTEMP contains the variables 
XXX, YYY, ZZZ, DESCR, and VOL. Input template ITARLE contains 
the variables III and DESCR. 

Now we run RUILD_EASIE to create the command procedures and 
the sorted data file. EASIE requires that a relation be created 
before a template can use it, so you must be sure to build the 
relations before building the templates. 
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$ RUN BUILD_EASIE 

B u i 1 d_E a s i e 

VER. 1.0 VAX/VMS - RIM, 5-5-87 

ENTER EASIE DATA FILE NAME, <CR> = EASIE.DAT 
-> EASIE.DAT 


ENTER: R <RELATIUN NAME> TO BUILD RELATIONS 

T <TEMPLATE NAME> TO BUILD TEMPLATES 

S TO SORT THE DATA FILE 

<CR> TO END 

-> R REL_1 

RELATION REL 1 COMPLETED 

-> R REL_2 

RELATION REL_2 COMPLETED 

-> T ITEMP 

TEMPLATE ITEMP COMPLETED 

-> T OTEMP 

TEMPLATE OTEMP COMPLETED 

-> S 

THE SORTED DATA IS IN FILE: SORT.DAT 

-> 

FORTRAN STOP 
$ DIR 

Directory DISK:[EASIE] 

BUILD EASIE.EXE;! EASIE.COM;! EASIE.DAT;! 

ITEMP.COM;! 

SORT.DAT ; ! 

Total of 5 files. 


We see that the command procedure EASIE.COM, the reviewer 
loader command procedure ITEMP.COM, and the sorted data file 
SORT.DAT have been created in our current directory. Notice 
that the template ITABLE is not listed in the directory because 
it was not specified to be built. EASIE.DAT may contain many 
relations and templates that are not referenced on any given run 
of BUILD EASIE. 
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Since this is a new EASIE system, we must create the ii 
dictionary. We run BUILDDICT.COM to create the files DICT 
DICT2.DAT, and DICT3.DAT. The symbol RIM must also exi 
execute RIM. 


$ RIM == "RUN DISK1:[RIM. RIM53RIM.EXE" 

$ 0TOAIDE:[BUILD_DICT]8UILDDICT.COM 

BEGIN RIM VAX VERSION 5.0 UD23 87/05/14 13.18.50 


RIM COMMAND MODE 

ENTER "MENU" FOR MENU MODE 

R> 

BEGIN RIM SCHEMA COMPILATION 


RIM SCHEMA COMPILATION FOR DICT IS COMPLETE 

EXISTING RELATIONS AS OF 87/05/14 13.19.15 

ATTRIB 

PARAM 

RELATION 

TEMPLATE 

TP.CNTRL 

TP. INDEX 

TP. SORT 

TP. WHERE 

TPC.INDX 

PROGRAM 

FORNAM 

FORTRAN STOP 
$ DIR 

Directory DISK:[EASIE] 

BUILD EASIE.EXE;! DICTl.DAT;! DICT2.DAT;1 DICT3.DAT;1 

EASIE.COM;! EASIE.DAT;! ITEMP.COM;! SORT.DAT;! 

Total of 8 files. 
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Next, the comnand file EASIE.COM is executed with the output 
written to RUNEASIE.OUT. The output can be very lengthy and is 
most often deleted. Rut the output file can be useful if 

problems develop when running EASIE.COM. With each subsequent 


executi on 

of 

EASIE.COM, 

the dictionary 

files 

(DICTl.OAT, 

DICT2.DAT, 

and 

DICT3.0AT) 

should be deleted 

and 

BUILDDICT.COM 


should be re-executed. 


Common problems that may develop when running EASIE.COM 
include: (a) no dictionary files in the current directory; 

(b) relation or template files not in the current directory; 

(c) relation or template already exists in the dictionary before 

EASIE.COM is run attempting to create that same relation or 
template; or (d) a template references a relation that has not 

been created. 

$ ffiASIE/OUTPUT=RUNEASIE.OUT 
$ DIR 

Directory DISK:[EASIE] 

BUILD_EASIE.EXE ;1 DATAOBl.DAT;! 

DICT1.DAT;! DICT2.DAT;1 

EASIE.DAT;! ITEMP.COM;! 

OTEMP.FOR;! OTEMP.REV;! 

S0RT.DAT;! 

Total of 17 files. 

A GETDATA routine is in ITEMP.FOR, and a PUTDATA routine is 
in OTEMP.FOR. The schema file is in SCHEMA.DAT. The directory 
listing shows the REVIEWER files and the three RIM database files 


nATA0B2.DAT;l 

DICT3.DAT;1 

ITEMP.FOR;! 

RUNEASIE.OUT;! 


DATADB3.DAT;! 

EASIE.COM;! 

ITEMP.REV;! 

SCHEMA.DAT;! 
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RUNEASIE.OUT , 


and 


are present. 


SCHEMA.DAT are often deleted at this point. 

We now look at the REVIEWER loader 1TEHP.COM. A 

familiarUy with the REVIEWER comoands (section 7) is needed to 
understand the contents of this file. The user must edit this 
file and change the zeroes to any value consistent with the 
variable's type. Variables of type CHARACTER must have values 
enclosed in double quotes. All lines in the tile not beginning 
with M must be left in place. Any lines beginning with M can be 
deleted if desired. After the proper values have been placed in 
the file, this command procedure may be executed to load 

database . 


$ TYPE ITEMP.COM 

$ DEFINE SYS$OUTPUT TRASH.DAT 
$ REVIEW ITEMP 


C REL_1 
M XXX 0 

M YYY(1 .1 ,1 ) 0 
M YYY(1,1,2) 0 
M YYY{1,2,1) 0 
M YYY(1,2,2) 0 
M YYY(1 ,3,1 ) 0 
M YYY (1 ,3,2) 0 
M YYY(2,1,1) 0 
M YYY(2,1,2) 0 
M YYY(2,2,1) 0 
M YYY(2,2,2) 0 
M YYY(2,3,1) 0 
M YYY(2,3,2) 0 
C REL_2 
M COUNT 0 


$ OEASSIGN SYSSOUTPUT 
$ DELETE TRASH.DAT;* 


The SORT. DAT file is shown on the following page. This file 
may be created to help track down variables in the data base and 
can be very useful during program development and integration. 
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$ TYPE SORT.DAT 


VARIABLE TYPE DIMENSION 
RELATION NAME 


UNITS FORMAT DESCRIPTION 
- TEMPLATE NAMES ... 


COUNT 

I 1 
REL 2 

DESCR 

C 8TT 1 
REL 2 

VOL 

R 1“ 
REL 2 

X 

X 

X 

R 1~ 
REL 1 

YYY 

I 2.3,2 
REL 1 

111 

R ?76 
REL 1 


+ 12 
ITEMP 

+ + 

OTEMP ITABLE 
M**3 + 

OTEMP 

FEET + 

ITEMP OTEMP 
INCHES 15 

ITEMP OTEMP 
METERS + 

OTEMP ITABLE 


NUMBER OF PARTS 
PROGRAM DESCRIPTION. 
VOLUME OF OBJECT 
DISTANCE TO SATELLITE 
SIZE OF PARTS 
COORDINATES 


$ 


APPENDIX F 

INSTRUCTIONS - EASIE CODING FORM 

When one computer program provides data used by another program, it may 
be more effect^ to InteVate these programs around a com,jon 'nfor^t on 
S!tr.?e and automate the data exchange rather than to manually perform the 
rfata exchanqe each time. These brief instructions explain which information 
about a variable will be needed to integrate that program 

into an EASIE central database system using 

niirnose Since the application programmer, who is the expert on cne 
definition of variables needed in the database, may not 
integration, he nay instead provide the needed information on this 
that another program implementer can do the job for him. 

In reference to the EASIE coding form, columns 2 through 6, 
ct ho fiiipri in bv the application programmer who can define for the 
Sidate program all^nput output iarlablas (names, descriptions, and 

•J 1 fhJ wiirhrUared with the central database. Obviously, all input 

expert can optionally fill in columns 1, 7. and 8 if such information 
helpful. (See explanation for these columns below.) 

mnr? used by the Implementer for 

building relations, database I/O subroutines, etc. 


A brief description of each column follows: 


used in the code. This is purely for the convenience of the application 
programmer and is intended to aid his bookkeeping. 


the 

the 


? Column 2 (required) is for listing al 1 , variabl es that are input to 

■ Sa?^^::e ^"‘tcotiln ^^‘10,^ ^ the 

which the data will be read/written from/to the database. 

3. Column 3 (required) specifies whether the variable is real ^ 

(I), double precision (D), or character u stated 

character, then the length of the character variable should be stated. 

4. If the variable is subscripted, column 4 should declare the dimensions of 
the array (up to three-dimensional arrays are allowed). 

5. Column 5 (required) Is the 

rh;iracters but should be given concisely in the first lb characters 
the field which the REVIEWER automatically displays for Parameter typ 
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only. If groups of input variables are somehow associated with various input 

indication of this grouping should also be included in the 
h 17-80 will not be automatically displayed, 
the REVIEWEr^*^^"^^ ^ selection) option provided by 


6 . 


Column 6 (required) gives the units of the variables which can he 

RFViFUFD*^ V" understandable fashion up to 16 characters. The 

REVIEWER automatical 1y displays 10 characters for Parameter Type only 

^ simple set of one- or two-character abbreviations will 
facilitate the possible later development of a units conversion 


utility. Examples of some 
PT feet 

ET2 feet squared 

LB pounds 

OR degrees Rankine 


abbreviations 
N-M 
NM 

LB/OY 


are: 

newton meters 
nautical miles 
pounds per day 


7. Column 7 (optional) can be used if the program expert wishes to see a 
variable displayed in a particular way when using the REVIEWER. 

8. Column 8 (optional) will allow the specification of a reference value for 
the variable. Such reference values could define a standard check case 
or typical run which would thus provide a coherent set of initial values 
for the database. Typically, at least the input values should be 
provided with reference values. If no values are given, data will be 
initialized in the database to zero or blank for character data. 

9. Column 9 (required) indicates whether a variable is an input (I) to the 
program or an output (0) from the program, or it might be both (B). 

10. Column 10 (if applicable) indicates if a variable is 
giving the common block name. 


in a common block by 


Columns H, 12. and 13 are not filled in by the application programmer, 
but are used by the program implementer. 

11. Column 11 is the attribute or parameter name. If the variable already 

<latabase by another name, the name as it already appears in 
the database must he used and will be given in this column. 

12. Column 12 contains the relation name. If the variable is new to the 
database, it may be placed in an existing relation or a new relation. 

PARAMETER assignment of the relation type (A-ATTRIBUTE or P- 

Please fill in the program name and contact person's name and 
phone number in the spaces provided at the top of the form. 
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VAX SYMBOL DEFINITIONS 


The following VAX logical and symbol definitions are used throughout this 
document: 

(1) TOAIDE - A logical defining the directory location of the EASIE software. 

(2) RUNDICT - A symbol used to execute the SYSTEM LIBRARY PROCESSOR. 

(3) RUNRIM - A symbol used to execute interactive RIM. 

(4) LOADRIM - A logical defining the directory location of the RIM FORTRAN 

1 ibrary. 

(5) REVIEW - A symbol used to execute the REVIEWER. 

These logicals and symbols are defined at the operating system level 
during installation of EASIE [5]. 
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ENTER DIRECTORY LOCATION FOR REVIEWER INPUT FILES 

OR <CR> TO CREATE A LOCAL REVIEWER FILE 

<CR> 

ENTER TEMPLATE NAME 

OR <CR> TO CREATE REVIEWER FILES FOR ALL TEMPLATES 
OR "Q” TO QUIT 
MAKGEOIN<CR> 


SELECT OPTION: 

BR - TO BUILO RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILO A TEMPLATE 

BF - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA BASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

BRV<CR> 

ENTER DIRECTORY LOCATION FOR REVIEWER INPUT FILES 

OR <CR> TO CREATE A LOCAL REVIEWER FILE 

<CR> 

ENTER TEMPLATE NAME 

OR <CR> TO CREATE REVIEWER FILES FOR ALL TEMPLATES 
OR "Q" TO QUIT 
DRAWIN<CR> 

ROW MODIFICATION FLAG FOR RELATION NODES : 

0 - FULL MODIFICATION 

1 - MODIFY BUT CANNOT ADD ROWS 

2 - CANNOT MODIFY ROWS 
2<CR> 

ROW MODIFICATION FLAG FOR RELATION FACES : 

0 - FULL MODIFICATION 

1 - MODIFY BUT CANNOT ADD ROWS 

2 - CANNOT MODIFY ROWS 
2<CR> 
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SELECT OPTION: 

BR - TO BUILD RELATIONS 

AR - TO ADD TO AN EXISTING RELATION 

BT - TO BUILD A TEMPLATE 

BE - TO BUILD FORMATTER ROUTINES 

BS - TO BUILD A SCHEMA DUMP FOR DATA RASE 

BRV - TO BUILD A REVIEWER INPUT FILE 

BP - TO BUILD PROGRAM DESCRIPTION 

PT - TO PRINT A TEMPLATE 

LR - TO LIST RELATIONS 

PR - TO PRINT A RELATION 

X - TO EXIT 

X<CR> 



